* [PATCH v5 12/22] ipc: fix mp message alignment for malloc
@ 2025-07-23 13:31 8% ` David Marchand
0 siblings, 0 replies; 15+ results
From: David Marchand @ 2025-07-23 13:31 UTC (permalink / raw)
To: dev; +Cc: Tyler Retzlaff
Content (param[]) of received multiprocess messages are aligned with
a 4 bytes constraint.
Before patch:
struct mp_msg_internal {
int type; /* 0 4 */
struct rte_mp_msg {
char name[64]; /* 4 64 */
/* --- cacheline 1 boundary (64 bytes) was 4 bytes ago --- */
int len_param; /* 68 4 */
int num_fds; /* 72 4 */
/* typedef uint8_t -> __uint8_t */ unsigned char param[256]; /* 76 256 */
/* --- cacheline 5 boundary (320 bytes) was 12 bytes ago --- */
int fds[253]; /* 332 1012 */
} msg; /* 4 1340 */
/* size: 1344, cachelines: 21, members: 2 */
};
This results in many unaligned accesses for multiprocess malloc requests.
Examples:
../lib/eal/common/malloc_mp.c:308:32: runtime error:
member access within misaligned address 0x7f7b35df4684 for type
'const struct malloc_mp_req', which requires 8 byte alignment
../lib/eal/common/malloc_mp.c:158:9: runtime error:
member access within misaligned address 0x7f36a535bb5c for type
'const struct malloc_mp_req', which requires 8 byte alignment
../lib/eal/common/malloc_mp.c:171:8: runtime error:
member access within misaligned address 0x7f4ba65f296c for type
'struct malloc_mp_req', which requires 8 byte alignment
Align param[] to 64 bits to avoid unaligned accesses on structures
passed through this array in mp messages.
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
Changes since v4:
- dropped ABI exception and updated RN,
Changes since v3:
- changed rte_mp_msg struct alignment,
---
doc/guides/rel_notes/release_25_11.rst | 4 +++-
lib/eal/include/rte_eal.h | 3 ++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/doc/guides/rel_notes/release_25_11.rst b/doc/guides/rel_notes/release_25_11.rst
index aa9211dd60..86cc59b4be 100644
--- a/doc/guides/rel_notes/release_25_11.rst
+++ b/doc/guides/rel_notes/release_25_11.rst
@@ -100,10 +100,12 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* eal: The structure ``rte_mp_msg`` alignment has been updated to 8 bytes to limit unaligned
+ accesses in messages payload.
+
* stack: The structure ``rte_stack_lf_head`` alignment has been updated to 16 bytes
to avoid unaligned accesses.
-
Known Issues
------------
diff --git a/lib/eal/include/rte_eal.h b/lib/eal/include/rte_eal.h
index c826e143f1..08977c61d3 100644
--- a/lib/eal/include/rte_eal.h
+++ b/lib/eal/include/rte_eal.h
@@ -11,6 +11,7 @@
* EAL Configuration API
*/
+#include <stdalign.h>
#include <stdint.h>
#include <time.h>
@@ -162,7 +163,7 @@ struct rte_mp_msg {
char name[RTE_MP_MAX_NAME_LEN];
int len_param;
int num_fds;
- uint8_t param[RTE_MP_MAX_PARAM_LEN];
+ alignas(8) uint8_t param[RTE_MP_MAX_PARAM_LEN];
int fds[RTE_MP_MAX_FD_NUM];
};
--
2.50.0
^ permalink raw reply [relevance 8%]
* RE: [PATCH 2/2] net: remove v25 ABI compatibility
@ 2025-07-24 10:10 4% ` Finn, Emma
0 siblings, 0 replies; 15+ results
From: Finn, Emma @ 2025-07-24 10:10 UTC (permalink / raw)
To: Marchand, David; +Cc: dev, thomas, Richardson, Bruce
> -----Original Message-----
> From: Bruce Richardson <bruce.richardson@intel.com>
> Sent: Wednesday 23 July 2025 13:15
> To: Marchand, David <david.marchand@redhat.com>
> Cc: dev@dpdk.org; thomas@monjalon.net
> Subject: Re: [PATCH 2/2] net: remove v25 ABI compatibility
>
> On Tue, Jul 22, 2025 at 03:24:41PM +0200, David Marchand wrote:
> > Now that the ABI has been bumped to 26, we can drop compatibility
> > symbols for the CRC API.
> >
> > The logtype is not used anymore and can be removed.
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > ---
>
> Not an expert in this area, but code changes look ok to me.
>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
>
I reviewed and tested. Changes look good to me too.
Acked-by: Emma Finn <emma.finn@intel.com>
^ permalink raw reply [relevance 4%]
* Re: [EXTERNAL] [PATCH] doc: announce DMA configuration structure changes
@ 2025-07-25 6:04 0% ` Pavan Nikhilesh Bhagavatula
2025-07-26 0:55 0% ` fengchengwen
0 siblings, 1 reply; 15+ results
From: Pavan Nikhilesh Bhagavatula @ 2025-07-25 6:04 UTC (permalink / raw)
To: Thomas Monjalon, Amit Prakash Shukla
Cc: Jerin Jacob, dev, Vamsi Krishna Attunuru, g.singh, sachin.saxena,
hemant.agrawal, fengchengwen, bruce.richardson, kevin.laatz,
conor.walsh, Gowrishankar Muthukrishnan, Vidya Sagar Velumuri,
anatoly.burakov
>> Deprecate rte_dma_conf structure to allow for a more flexible
>> configuration of DMA devices.
>> The new structure will have a flags field instead of multiple
>> boolean fields for each feature.
>>
>> Signed-off-by: Pavan Nikhilesh <mailto:pbhagavatula@marvell.com>
>> ---
>> +* dmadev: The ``rte_dma_conf`` structure is updated to include a new field
>> + ``rte_dma_conf::flags`` that should be used to configure dmadev features.
>> + The existing field ``rte_dma_conf::enable_silent`` is removed and replaced
>> + with the new flag ``RTE_DMA_CFG_FLAG_SILENT``, to configure silent mode
>> + the flag should be set in ``rte_dma_conf::flags`` during device configuration.
>>
>> Acked-by: Amit Prakash Shukla <amitprakashs@marvell.com>
>
>There is only 1 ack.
>Per our policy, it will miss the release 25.07.
>
>You can probably do this change anyway,
>and keep ABI compatibility by versioning the function.
Hi Fengchengwen,
Are you ok with this change? If so please ack it so that I can work on getting
an exception from techboard to merge this without deprecation notice in 25.11.
Thanks,
Pavan.
^ permalink raw reply [relevance 0%]
* Re: [EXTERNAL] [PATCH] doc: announce DMA configuration structure changes
2025-07-25 6:04 0% ` Pavan Nikhilesh Bhagavatula
@ 2025-07-26 0:55 0% ` fengchengwen
2025-07-28 5:11 4% ` Pavan Nikhilesh Bhagavatula
0 siblings, 1 reply; 15+ results
From: fengchengwen @ 2025-07-26 0:55 UTC (permalink / raw)
To: Pavan Nikhilesh Bhagavatula, Thomas Monjalon, Amit Prakash Shukla
Cc: Jerin Jacob, dev, Vamsi Krishna Attunuru, g.singh, sachin.saxena,
hemant.agrawal, bruce.richardson, kevin.laatz, conor.walsh,
Gowrishankar Muthukrishnan, Vidya Sagar Velumuri,
anatoly.burakov
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
On 2025/7/25 14:04, Pavan Nikhilesh Bhagavatula wrote:
>>> Deprecate rte_dma_conf structure to allow for a more flexible
>>> configuration of DMA devices.
>>> The new structure will have a flags field instead of multiple
>>> boolean fields for each feature.
>>>
>>> Signed-off-by: Pavan Nikhilesh <mailto:pbhagavatula@marvell.com>
>>> ---
>>> +* dmadev: The ``rte_dma_conf`` structure is updated to include a new field
>>> + ``rte_dma_conf::flags`` that should be used to configure dmadev features.
>>> + The existing field ``rte_dma_conf::enable_silent`` is removed and replaced
>>> + with the new flag ``RTE_DMA_CFG_FLAG_SILENT``, to configure silent mode
>>> + the flag should be set in ``rte_dma_conf::flags`` during device configuration.
>>>
>>> Acked-by: Amit Prakash Shukla <amitprakashs@marvell.com>
>>
>> There is only 1 ack.
>> Per our policy, it will miss the release 25.07.
>>
>> You can probably do this change anyway,
>> and keep ABI compatibility by versioning the function.
>
> Hi Fengchengwen,
>
> Are you ok with this change? If so please ack it so that I can work on getting
> an exception from techboard to merge this without deprecation notice in 25.11.
>
> Thanks,
> Pavan.
>
^ permalink raw reply [relevance 0%]
* Re: [EXTERNAL] [PATCH] doc: announce DMA configuration structure changes
2025-07-26 0:55 0% ` fengchengwen
@ 2025-07-28 5:11 4% ` Pavan Nikhilesh Bhagavatula
2025-08-12 10:59 0% ` Thomas Monjalon
0 siblings, 1 reply; 15+ results
From: Pavan Nikhilesh Bhagavatula @ 2025-07-28 5:11 UTC (permalink / raw)
To: fengchengwen, techboard, Thomas Monjalon, Amit Prakash Shukla
Cc: Jerin Jacob, dev, Vamsi Krishna Attunuru, g.singh, sachin.saxena,
hemant.agrawal, bruce.richardson, kevin.laatz, conor.walsh,
Gowrishankar Muthukrishnan, Vidya Sagar Velumuri,
anatoly.burakov
>Acked-by: Chengwen Feng <fengchengwen@huawei.com>
>
Thomas,
Now that Feng Chengwen is ok with this change, can this be merged
along with the ABI breaking changes in 25.11?
Given that techboard approves the change.
This change helps reduce ABI breakage when a new feature is added.
Thanks,
Pavan.
>On 2025/7/25 14:04, Pavan Nikhilesh Bhagavatula wrote:
>>>> Deprecate rte_dma_conf structure to allow for a more flexible
>>>> configuration of DMA devices.
>>>> The new structure will have a flags field instead of multiple
>>>> boolean fields for each feature.
>>>>
>>>> Signed-off-by: Pavan Nikhilesh <mailto:pbhagavatula@marvell.com>
>>>> ---
>>>> +* dmadev: The ``rte_dma_conf`` structure is updated to include a new field
>>>> + ``rte_dma_conf::flags`` that should be used to configure dmadev features.
>>>> + The existing field ``rte_dma_conf::enable_silent`` is removed and replaced
>>>> + with the new flag ``RTE_DMA_CFG_FLAG_SILENT``, to configure silent mode
>>>> + the flag should be set in ``rte_dma_conf::flags`` during device configuration.
>>>>
>>>> Acked-by: Amit Prakash Shukla <amitprakashs@marvell.com>
>>>
>>> There is only 1 ack.
>>> Per our policy, it will miss the release 25.07.
>>>
>>> You can probably do this change anyway,
>>> and keep ABI compatibility by versioning the function.
>>
>> Hi Fengchengwen,
>>
>> Are you ok with this change? If so please ack it so that I can work on getting
>> an exception from techboard to merge this without deprecation notice in 25.11.
>>
>> Thanks,
>> Pavan.
>>
^ permalink raw reply [relevance 4%]
* RE: [PATCH v12 01/10] mbuf: replace term sanity check
@ 2025-08-11 9:55 0% ` Morten Brørup
2025-08-11 15:20 0% ` Stephen Hemminger
0 siblings, 1 reply; 15+ results
From: Morten Brørup @ 2025-08-11 9:55 UTC (permalink / raw)
To: Stephen Hemminger, dev; +Cc: Andrew Rybchenko, Akhil Goyal, Fan Zhang
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Thursday, 3 April 2025 01.23
>
> Replace rte_mbuf_sanity_check() with rte_mbuf_verify()
> to match the similar macro RTE_VERIFY() in rte_debug.h
>
> The term sanity check is on the Tier 2 list of words
> that should be replaced.
>
> For this release keep old API functions but mark them
> as deprecated.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> ---
> app/test/test_cryptodev.c | 2 +-
> app/test/test_mbuf.c | 28 +++++-----
> doc/guides/prog_guide/mbuf_lib.rst | 4 +-
> doc/guides/rel_notes/deprecation.rst | 3 ++
> lib/mbuf/rte_mbuf.c | 23 +++++---
> lib/mbuf/rte_mbuf.h | 79 +++++++++++++++-------------
> lib/mbuf/version.map | 1 +
> 7 files changed, 79 insertions(+), 61 deletions(-)
>
> diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
> index 31a4905a97..d5f3843daf 100644
> --- a/app/test/test_cryptodev.c
> +++ b/app/test/test_cryptodev.c
> @@ -264,7 +264,7 @@ create_mbuf_from_heap(int pkt_len, uint8_t pattern)
> m->port = RTE_MBUF_PORT_INVALID;
> m->buf_len = MBUF_SIZE - sizeof(struct rte_mbuf) - RTE_PKTMBUF_HEADROOM;
> rte_pktmbuf_reset_headroom(m);
> - __rte_mbuf_sanity_check(m, 1);
> + __rte_mbuf_verify(m, 1);
>
> m->buf_addr = (char *)m + sizeof(struct rte_mbuf) +
> RTE_PKTMBUF_HEADROOM;
>
> diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
> index 17be977f31..3fbb5dea8b 100644
> --- a/app/test/test_mbuf.c
> +++ b/app/test/test_mbuf.c
> @@ -262,8 +262,8 @@ test_one_pktmbuf(struct rte_mempool *pktmbuf_pool)
> GOTO_FAIL("Buffer should be continuous");
> memset(hdr, 0x55, MBUF_TEST_HDR2_LEN);
>
> - rte_mbuf_sanity_check(m, 1);
> - rte_mbuf_sanity_check(m, 0);
> + rte_mbuf_verify(m, 1);
> + rte_mbuf_verify(m, 0);
> rte_pktmbuf_dump(stdout, m, 0);
>
> /* this prepend should fail */
> @@ -1162,7 +1162,7 @@ test_refcnt_mbuf(void)
>
> #ifdef RTE_EXEC_ENV_WINDOWS
> static int
> -test_failing_mbuf_sanity_check(struct rte_mempool *pktmbuf_pool)
> +test_failing_mbuf_verify(struct rte_mempool *pktmbuf_pool)
> {
> RTE_SET_USED(pktmbuf_pool);
> return TEST_SKIPPED;
> @@ -1181,12 +1181,12 @@ mbuf_check_pass(struct rte_mbuf *buf)
> }
>
> static int
> -test_failing_mbuf_sanity_check(struct rte_mempool *pktmbuf_pool)
> +test_failing_mbuf_verify(struct rte_mempool *pktmbuf_pool)
> {
> struct rte_mbuf *buf;
> struct rte_mbuf badbuf;
>
> - printf("Checking rte_mbuf_sanity_check for failure conditions\n");
> + printf("Checking rte_mbuf_verify for failure conditions\n");
>
> /* get a good mbuf to use to make copies */
> buf = rte_pktmbuf_alloc(pktmbuf_pool);
> @@ -1708,7 +1708,7 @@ test_mbuf_validate_tx_offload(const char *test_name,
> GOTO_FAIL("%s: mbuf allocation failed!\n", __func__);
> if (rte_pktmbuf_pkt_len(m) != 0)
> GOTO_FAIL("%s: Bad packet length\n", __func__);
> - rte_mbuf_sanity_check(m, 0);
> + rte_mbuf_verify(m, 0);
> m->ol_flags = ol_flags;
> m->tso_segsz = segsize;
> ret = rte_validate_tx_offload(m);
> @@ -1915,7 +1915,7 @@ test_pktmbuf_read(struct rte_mempool *pktmbuf_pool)
> GOTO_FAIL("%s: mbuf allocation failed!\n", __func__);
> if (rte_pktmbuf_pkt_len(m) != 0)
> GOTO_FAIL("%s: Bad packet length\n", __func__);
> - rte_mbuf_sanity_check(m, 0);
> + rte_mbuf_verify(m, 0);
>
> data = rte_pktmbuf_append(m, MBUF_TEST_DATA_LEN2);
> if (data == NULL)
> @@ -1964,7 +1964,7 @@ test_pktmbuf_read_from_offset(struct rte_mempool
> *pktmbuf_pool)
>
> if (rte_pktmbuf_pkt_len(m) != 0)
> GOTO_FAIL("%s: Bad packet length\n", __func__);
> - rte_mbuf_sanity_check(m, 0);
> + rte_mbuf_verify(m, 0);
>
> /* prepend an ethernet header */
> hdr = (struct ether_hdr *)rte_pktmbuf_prepend(m, hdr_len);
> @@ -2109,7 +2109,7 @@ create_packet(struct rte_mempool *pktmbuf_pool,
> GOTO_FAIL("%s: mbuf allocation failed!\n", __func__);
> if (rte_pktmbuf_pkt_len(pkt_seg) != 0)
> GOTO_FAIL("%s: Bad packet length\n", __func__);
> - rte_mbuf_sanity_check(pkt_seg, 0);
> + rte_mbuf_verify(pkt_seg, 0);
> /* Add header only for the first segment */
> if (test_data->flags == MBUF_HEADER && seg == 0) {
> hdr_len = sizeof(struct rte_ether_hdr);
> @@ -2321,7 +2321,7 @@ test_pktmbuf_ext_shinfo_init_helper(struct rte_mempool
> *pktmbuf_pool)
> GOTO_FAIL("%s: mbuf allocation failed!\n", __func__);
> if (rte_pktmbuf_pkt_len(m) != 0)
> GOTO_FAIL("%s: Bad packet length\n", __func__);
> - rte_mbuf_sanity_check(m, 0);
> + rte_mbuf_verify(m, 0);
>
> ext_buf_addr = rte_malloc("External buffer", buf_len,
> RTE_CACHE_LINE_SIZE);
> @@ -2482,8 +2482,8 @@ test_pktmbuf_ext_pinned_buffer(struct rte_mempool
> *std_pool)
> GOTO_FAIL("%s: test_pktmbuf_copy(pinned) failed\n",
> __func__);
>
> - if (test_failing_mbuf_sanity_check(pinned_pool) < 0)
> - GOTO_FAIL("%s: test_failing_mbuf_sanity_check(pinned)"
> + if (test_failing_mbuf_verify(pinned_pool) < 0)
> + GOTO_FAIL("%s: test_failing_mbuf_verify(pinned)"
> " failed\n", __func__);
>
> if (test_mbuf_linearize_check(pinned_pool) < 0)
> @@ -2857,8 +2857,8 @@ test_mbuf(void)
> goto err;
> }
>
> - if (test_failing_mbuf_sanity_check(pktmbuf_pool) < 0) {
> - printf("test_failing_mbuf_sanity_check() failed\n");
> + if (test_failing_mbuf_verify(pktmbuf_pool) < 0) {
> + printf("test_failing_mbuf_verify() failed\n");
> goto err;
> }
>
> diff --git a/doc/guides/prog_guide/mbuf_lib.rst
> b/doc/guides/prog_guide/mbuf_lib.rst
> index 4ad2a21f3f..6c96931f8c 100644
> --- a/doc/guides/prog_guide/mbuf_lib.rst
> +++ b/doc/guides/prog_guide/mbuf_lib.rst
> @@ -266,8 +266,8 @@ can be found in several of the sample applications, for
> example, the IPv4 Multic
> Debug
> -----
>
> -In debug mode, the functions of the mbuf library perform sanity checks before
> any operation (such as, buffer corruption,
> -bad type, and so on).
> +In debug mode, the functions of the mbuf library perform consistency checks
> +before any operation (such as, buffer corruption, bad type, and so on).
>
> Use Cases
> ---------
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index 36489f6e68..10bb08a634 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -142,3 +142,6 @@ Deprecation Notices
> * bus/vmbus: Starting DPDK 25.11, all the vmbus API defined in
> ``drivers/bus/vmbus/rte_bus_vmbus.h`` will become internal to DPDK.
> Those API functions are used internally by DPDK core and netvsc PMD.
> +
> +* mbuf: The function ``rte_mbuf_sanity_check`` is deprecated.
> + Use the new function ``rte_mbuf_verify`` instead.
> diff --git a/lib/mbuf/rte_mbuf.c b/lib/mbuf/rte_mbuf.c
> index 559d5ad8a7..fc5d4ba29d 100644
> --- a/lib/mbuf/rte_mbuf.c
> +++ b/lib/mbuf/rte_mbuf.c
> @@ -367,9 +367,9 @@ rte_pktmbuf_pool_create_extbuf(const char *name, unsigned
> int n,
> return mp;
> }
>
> -/* do some sanity checks on a mbuf: panic if it fails */
> +/* do some checks on a mbuf: panic if it fails */
> void
> -rte_mbuf_sanity_check(const struct rte_mbuf *m, int is_header)
> +rte_mbuf_verify(const struct rte_mbuf *m, int is_header)
> {
> const char *reason;
>
> @@ -377,6 +377,13 @@ rte_mbuf_sanity_check(const struct rte_mbuf *m, int
> is_header)
> rte_panic("%s\n", reason);
> }
>
> +/* For ABI compatibility, to be removed in next release */
> +void
> +rte_mbuf_sanity_check(const struct rte_mbuf *m, int is_header)
> +{
> + rte_mbuf_verify(m, is_header);
> +}
> +
> int rte_mbuf_check(const struct rte_mbuf *m, int is_header,
> const char **reason)
> {
> @@ -496,7 +503,7 @@ void rte_pktmbuf_free_bulk(struct rte_mbuf **mbufs,
> unsigned int count)
> if (unlikely(m == NULL))
> continue;
>
> - __rte_mbuf_sanity_check(m, 1);
> + __rte_mbuf_verify(m, 1);
>
> do {
> m_next = m->next;
> @@ -546,7 +553,7 @@ rte_pktmbuf_clone(struct rte_mbuf *md, struct rte_mempool
> *mp)
> return NULL;
> }
>
> - __rte_mbuf_sanity_check(mc, 1);
> + __rte_mbuf_verify(mc, 1);
> return mc;
> }
>
> @@ -596,7 +603,7 @@ rte_pktmbuf_copy(const struct rte_mbuf *m, struct
> rte_mempool *mp,
> struct rte_mbuf *mc, *m_last, **prev;
>
> /* garbage in check */
> - __rte_mbuf_sanity_check(m, 1);
> + __rte_mbuf_verify(m, 1);
>
> /* check for request to copy at offset past end of mbuf */
> if (unlikely(off >= m->pkt_len))
> @@ -660,7 +667,7 @@ rte_pktmbuf_copy(const struct rte_mbuf *m, struct
> rte_mempool *mp,
> }
>
> /* garbage out check */
> - __rte_mbuf_sanity_check(mc, 1);
> + __rte_mbuf_verify(mc, 1);
> return mc;
> }
>
> @@ -671,7 +678,7 @@ rte_pktmbuf_dump(FILE *f, const struct rte_mbuf *m,
> unsigned dump_len)
> unsigned int len;
> unsigned int nb_segs;
>
> - __rte_mbuf_sanity_check(m, 1);
> + __rte_mbuf_verify(m, 1);
>
> fprintf(f, "dump mbuf at %p, iova=%#" PRIx64 ", buf_len=%u\n", m,
> rte_mbuf_iova_get(m),
> m->buf_len);
> @@ -689,7 +696,7 @@ rte_pktmbuf_dump(FILE *f, const struct rte_mbuf *m,
> unsigned dump_len)
> nb_segs = m->nb_segs;
>
> while (m && nb_segs != 0) {
> - __rte_mbuf_sanity_check(m, 0);
> + __rte_mbuf_verify(m, 0);
>
> fprintf(f, " segment at %p, data=%p, len=%u, off=%u,
> refcnt=%u\n",
> m, rte_pktmbuf_mtod(m, void *),
> diff --git a/lib/mbuf/rte_mbuf.h b/lib/mbuf/rte_mbuf.h
> index 06ab7502a5..53a837e4d5 100644
> --- a/lib/mbuf/rte_mbuf.h
> +++ b/lib/mbuf/rte_mbuf.h
> @@ -339,16 +339,20 @@ rte_pktmbuf_priv_flags(struct rte_mempool *mp)
>
> #ifdef RTE_LIBRTE_MBUF_DEBUG
>
> -/** check mbuf type in debug mode */
> -#define __rte_mbuf_sanity_check(m, is_h) rte_mbuf_sanity_check(m, is_h)
> +/** do mbuf type in debug mode */
> +#define __rte_mbuf_verify(m, is_h) rte_mbuf_verify(m, is_h)
>
> #else /* RTE_LIBRTE_MBUF_DEBUG */
>
> -/** check mbuf type in debug mode */
> -#define __rte_mbuf_sanity_check(m, is_h) do { } while (0)
> +/** ignore mbuf checks if not in debug mode */
> +#define __rte_mbuf_verify(m, is_h) do { } while (0)
>
> #endif /* RTE_LIBRTE_MBUF_DEBUG */
>
> +/* deprecated version of the macro */
> +#define __rte_mbuf_sanity_check(m, is_h)
> RTE_DEPRECATED(__rte_mbuf_sanity_check) \
> + __rte_mbuf_verify(m, is_h)
> +
> #ifdef RTE_MBUF_REFCNT_ATOMIC
>
> /**
> @@ -514,10 +518,9 @@ rte_mbuf_ext_refcnt_update(struct
> rte_mbuf_ext_shared_info *shinfo,
>
>
> /**
> - * Sanity checks on an mbuf.
> + * Check that the mbuf is valid and panic if corrupted.
> *
> - * Check the consistency of the given mbuf. The function will cause a
> - * panic if corruption is detected.
> + * Acts assertion that mbuf is consistent. If not it calls rte_panic().
> *
> * @param m
> * The mbuf to be checked.
> @@ -526,13 +529,17 @@ rte_mbuf_ext_refcnt_update(struct
> rte_mbuf_ext_shared_info *shinfo,
> * of a packet (in this case, some fields like nb_segs are not checked)
> */
> void
> +rte_mbuf_verify(const struct rte_mbuf *m, int is_header);
> +
> +__rte_deprecated
> +void
> rte_mbuf_sanity_check(const struct rte_mbuf *m, int is_header);
>
> /**
> - * Sanity checks on a mbuf.
> + * Do consistency checks on a mbuf.
> *
> - * Almost like rte_mbuf_sanity_check(), but this function gives the reason
> - * if corruption is detected rather than panic.
> + * Check the consistency of the given mbuf and if not valid
> + * return the reason.
> *
> * @param m
> * The mbuf to be checked.
> @@ -551,7 +558,7 @@ int rte_mbuf_check(const struct rte_mbuf *m, int
> is_header,
> const char **reason);
>
> /**
> - * Sanity checks on a reinitialized mbuf in debug mode.
> + * Do checks on a reinitialized mbuf in debug mode.
> *
> * Check the consistency of the given reinitialized mbuf.
> * The function will cause a panic if corruption is detected.
> @@ -563,7 +570,7 @@ int rte_mbuf_check(const struct rte_mbuf *m, int
> is_header,
> * The mbuf to be checked.
> */
> static __rte_always_inline void
> -__rte_mbuf_raw_sanity_check(__rte_unused const struct rte_mbuf *m)
> +__rte_mbuf_raw_verify(__rte_unused const struct rte_mbuf *m)
> {
> RTE_ASSERT(rte_mbuf_refcnt_read(m) == 1);
> RTE_ASSERT(m->next == NULL);
> @@ -572,11 +579,11 @@ __rte_mbuf_raw_sanity_check(__rte_unused const struct
> rte_mbuf *m)
> RTE_ASSERT(!RTE_MBUF_HAS_EXTBUF(m) ||
> (RTE_MBUF_HAS_PINNED_EXTBUF(m) &&
> rte_mbuf_ext_refcnt_read(m->shinfo) == 1));
> - __rte_mbuf_sanity_check(m, 0);
> + __rte_mbuf_verify(m, 0);
> }
>
> /** For backwards compatibility. */
> -#define MBUF_RAW_ALLOC_CHECK(m) __rte_mbuf_raw_sanity_check(m)
> +#define MBUF_RAW_ALLOC_CHECK(m) __rte_mbuf_raw_verify(m)
>
> /**
> * Allocate an uninitialized mbuf from mempool *mp*.
> @@ -606,7 +613,7 @@ static inline struct rte_mbuf *rte_mbuf_raw_alloc(struct
> rte_mempool *mp)
>
> if (rte_mempool_get(mp, &ret.ptr) < 0)
> return NULL;
> - __rte_mbuf_raw_sanity_check(ret.m);
> + __rte_mbuf_raw_verify(ret.m);
> return ret.m;
> }
>
> @@ -644,7 +651,7 @@ rte_mbuf_raw_alloc_bulk(struct rte_mempool *mp, struct
> rte_mbuf **mbufs, unsigne
> int rc = rte_mempool_get_bulk(mp, (void **)mbufs, count);
> if (likely(rc == 0))
> for (unsigned int idx = 0; idx < count; idx++)
> - __rte_mbuf_raw_sanity_check(mbufs[idx]);
> + __rte_mbuf_raw_verify(mbufs[idx]);
> return rc;
> }
>
> @@ -665,7 +672,7 @@ rte_mbuf_raw_alloc_bulk(struct rte_mempool *mp, struct
> rte_mbuf **mbufs, unsigne
> static __rte_always_inline void
> rte_mbuf_raw_free(struct rte_mbuf *m)
> {
> - __rte_mbuf_raw_sanity_check(m);
> + __rte_mbuf_raw_verify(m);
> rte_mempool_put(m->pool, m);
> }
>
> @@ -700,7 +707,7 @@ rte_mbuf_raw_free_bulk(struct rte_mempool *mp, struct
> rte_mbuf **mbufs, unsigned
> const struct rte_mbuf *m = mbufs[idx];
> RTE_ASSERT(m != NULL);
> RTE_ASSERT(m->pool == mp);
> - __rte_mbuf_raw_sanity_check(m);
> + __rte_mbuf_raw_verify(m);
> }
>
> rte_mempool_put_bulk(mp, (void **)mbufs, count);
> @@ -965,7 +972,7 @@ static inline void rte_pktmbuf_reset(struct rte_mbuf *m)
> rte_pktmbuf_reset_headroom(m);
>
> m->data_len = 0;
> - __rte_mbuf_sanity_check(m, 1);
> + __rte_mbuf_verify(m, 1);
> }
>
> /**
> @@ -1021,22 +1028,22 @@ static inline int rte_pktmbuf_alloc_bulk(struct
> rte_mempool *pool,
> switch (count % 4) {
> case 0:
> while (idx != count) {
> - __rte_mbuf_raw_sanity_check(mbufs[idx]);
> + __rte_mbuf_raw_verify(mbufs[idx]);
> rte_pktmbuf_reset(mbufs[idx]);
> idx++;
> /* fall-through */
> case 3:
> - __rte_mbuf_raw_sanity_check(mbufs[idx]);
> + __rte_mbuf_raw_verify(mbufs[idx]);
> rte_pktmbuf_reset(mbufs[idx]);
> idx++;
> /* fall-through */
> case 2:
> - __rte_mbuf_raw_sanity_check(mbufs[idx]);
> + __rte_mbuf_raw_verify(mbufs[idx]);
> rte_pktmbuf_reset(mbufs[idx]);
> idx++;
> /* fall-through */
> case 1:
> - __rte_mbuf_raw_sanity_check(mbufs[idx]);
> + __rte_mbuf_raw_verify(mbufs[idx]);
> rte_pktmbuf_reset(mbufs[idx]);
> idx++;
> /* fall-through */
> @@ -1267,8 +1274,8 @@ static inline void rte_pktmbuf_attach(struct rte_mbuf
> *mi, struct rte_mbuf *m)
> mi->pkt_len = mi->data_len;
> mi->nb_segs = 1;
>
> - __rte_mbuf_sanity_check(mi, 1);
> - __rte_mbuf_sanity_check(m, 0);
> + __rte_mbuf_verify(mi, 1);
> + __rte_mbuf_verify(m, 0);
> }
>
> /**
> @@ -1423,7 +1430,7 @@ static inline int
> __rte_pktmbuf_pinned_extbuf_decref(struct rte_mbuf *m)
> static __rte_always_inline struct rte_mbuf *
> rte_pktmbuf_prefree_seg(struct rte_mbuf *m)
> {
> - __rte_mbuf_sanity_check(m, 0);
> + __rte_mbuf_verify(m, 0);
>
> if (likely(rte_mbuf_refcnt_read(m) == 1)) {
>
> @@ -1494,7 +1501,7 @@ static inline void rte_pktmbuf_free(struct rte_mbuf *m)
> struct rte_mbuf *m_next;
>
> if (m != NULL)
> - __rte_mbuf_sanity_check(m, 1);
> + __rte_mbuf_verify(m, 1);
>
> while (m != NULL) {
> m_next = m->next;
> @@ -1575,7 +1582,7 @@ rte_pktmbuf_copy(const struct rte_mbuf *m, struct
> rte_mempool *mp,
> */
> static inline void rte_pktmbuf_refcnt_update(struct rte_mbuf *m, int16_t v)
> {
> - __rte_mbuf_sanity_check(m, 1);
> + __rte_mbuf_verify(m, 1);
>
> do {
> rte_mbuf_refcnt_update(m, v);
> @@ -1592,7 +1599,7 @@ static inline void rte_pktmbuf_refcnt_update(struct
> rte_mbuf *m, int16_t v)
> */
> static inline uint16_t rte_pktmbuf_headroom(const struct rte_mbuf *m)
> {
> - __rte_mbuf_sanity_check(m, 0);
> + __rte_mbuf_verify(m, 0);
> return m->data_off;
> }
>
> @@ -1606,7 +1613,7 @@ static inline uint16_t rte_pktmbuf_headroom(const struct
> rte_mbuf *m)
> */
> static inline uint16_t rte_pktmbuf_tailroom(const struct rte_mbuf *m)
> {
> - __rte_mbuf_sanity_check(m, 0);
> + __rte_mbuf_verify(m, 0);
> return (uint16_t)(m->buf_len - rte_pktmbuf_headroom(m) -
> m->data_len);
> }
> @@ -1621,7 +1628,7 @@ static inline uint16_t rte_pktmbuf_tailroom(const struct
> rte_mbuf *m)
> */
> static inline struct rte_mbuf *rte_pktmbuf_lastseg(struct rte_mbuf *m)
> {
> - __rte_mbuf_sanity_check(m, 1);
> + __rte_mbuf_verify(m, 1);
> while (m->next != NULL)
> m = m->next;
> return m;
> @@ -1665,7 +1672,7 @@ static inline struct rte_mbuf
> *rte_pktmbuf_lastseg(struct rte_mbuf *m)
> static inline char *rte_pktmbuf_prepend(struct rte_mbuf *m,
> uint16_t len)
> {
> - __rte_mbuf_sanity_check(m, 1);
> + __rte_mbuf_verify(m, 1);
>
> if (unlikely(len > rte_pktmbuf_headroom(m)))
> return NULL;
> @@ -1700,7 +1707,7 @@ static inline char *rte_pktmbuf_append(struct rte_mbuf
> *m, uint16_t len)
> void *tail;
> struct rte_mbuf *m_last;
>
> - __rte_mbuf_sanity_check(m, 1);
> + __rte_mbuf_verify(m, 1);
>
> m_last = rte_pktmbuf_lastseg(m);
> if (unlikely(len > rte_pktmbuf_tailroom(m_last)))
> @@ -1728,7 +1735,7 @@ static inline char *rte_pktmbuf_append(struct rte_mbuf
> *m, uint16_t len)
> */
> static inline char *rte_pktmbuf_adj(struct rte_mbuf *m, uint16_t len)
> {
> - __rte_mbuf_sanity_check(m, 1);
> + __rte_mbuf_verify(m, 1);
>
> if (unlikely(len > m->data_len))
> return NULL;
> @@ -1760,7 +1767,7 @@ static inline int rte_pktmbuf_trim(struct rte_mbuf *m,
> uint16_t len)
> {
> struct rte_mbuf *m_last;
>
> - __rte_mbuf_sanity_check(m, 1);
> + __rte_mbuf_verify(m, 1);
>
> m_last = rte_pktmbuf_lastseg(m);
> if (unlikely(len > m_last->data_len))
> @@ -1782,7 +1789,7 @@ static inline int rte_pktmbuf_trim(struct rte_mbuf *m,
> uint16_t len)
> */
> static inline int rte_pktmbuf_is_contiguous(const struct rte_mbuf *m)
> {
> - __rte_mbuf_sanity_check(m, 1);
> + __rte_mbuf_verify(m, 1);
> return m->nb_segs == 1;
> }
>
> diff --git a/lib/mbuf/version.map b/lib/mbuf/version.map
> index 76f1832924..2950f24caa 100644
> --- a/lib/mbuf/version.map
> +++ b/lib/mbuf/version.map
> @@ -31,6 +31,7 @@ DPDK_25 {
> rte_mbuf_set_platform_mempool_ops;
> rte_mbuf_set_user_mempool_ops;
> rte_mbuf_user_mempool_ops;
> + rte_mbuf_verify;
> rte_pktmbuf_clone;
> rte_pktmbuf_copy;
> rte_pktmbuf_dump;
> --
> 2.47.2
Stephen,
I have submitted another patch [1], where __rte_mbuf_raw_sanity_check()'s successor takes one more parameter, so I had to give it a new name __rte_mbuf_raw_sanity_check_mp() for API compatibility. And then I added:
+/** For backwards compatibility. */
+#define __rte_mbuf_raw_sanity_check(m) __rte_mbuf_raw_sanity_check_mp(m, NULL)
If you proceed with your patch, __rte_mbuf_raw_sanity_check() will be renamed to __rte_mbuf_raw_verify(), and __rte_mbuf_raw_sanity_check() disappears.
Would it make sense to change your patch, so __rte_mbuf_raw_verify() replaces __rte_mbuf_raw_sanity_check_mp() instead of __rte_mbuf_raw_sanity_check()? If your patch changes the API anyway, adding an extra parameter to the function should be acceptable.
[1]: https://patchwork.dpdk.org/project/dpdk/patch/20250722093431.555214-1-mb@smartsharesystems.com/
^ permalink raw reply [relevance 0%]
* Re: [PATCH v12 01/10] mbuf: replace term sanity check
2025-08-11 9:55 0% ` Morten Brørup
@ 2025-08-11 15:20 0% ` Stephen Hemminger
0 siblings, 0 replies; 15+ results
From: Stephen Hemminger @ 2025-08-11 15:20 UTC (permalink / raw)
To: Morten Brørup; +Cc: dev, Andrew Rybchenko, Akhil Goyal, Fan Zhang
On Mon, 11 Aug 2025 11:55:31 +0200
Morten Brørup <mb@smartsharesystems.com> wrote:
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Thursday, 3 April 2025 01.23
> >
> > Replace rte_mbuf_sanity_check() with rte_mbuf_verify()
> > to match the similar macro RTE_VERIFY() in rte_debug.h
> >
> > The term sanity check is on the Tier 2 list of words
> > that should be replaced.
> >
> > For this release keep old API functions but mark them
> > as deprecated.
> >
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > ---
> > app/test/test_cryptodev.c | 2 +-
> > app/test/test_mbuf.c | 28 +++++-----
> > doc/guides/prog_guide/mbuf_lib.rst | 4 +-
> > doc/guides/rel_notes/deprecation.rst | 3 ++
> > lib/mbuf/rte_mbuf.c | 23 +++++---
> > lib/mbuf/rte_mbuf.h | 79 +++++++++++++++-------------
> > lib/mbuf/version.map | 1 +
> > 7 files changed, 79 insertions(+), 61 deletions(-)
> >
> > diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
> > index 31a4905a97..d5f3843daf 100644
> > --- a/app/test/test_cryptodev.c
> > +++ b/app/test/test_cryptodev.c
> > @@ -264,7 +264,7 @@ create_mbuf_from_heap(int pkt_len, uint8_t pattern)
> > m->port = RTE_MBUF_PORT_INVALID;
> > m->buf_len = MBUF_SIZE - sizeof(struct rte_mbuf) - RTE_PKTMBUF_HEADROOM;
> > rte_pktmbuf_reset_headroom(m);
> > - __rte_mbuf_sanity_check(m, 1);
> > + __rte_mbuf_verify(m, 1);
> >
> > m->buf_addr = (char *)m + sizeof(struct rte_mbuf) +
> > RTE_PKTMBUF_HEADROOM;
> >
> > diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
> > index 17be977f31..3fbb5dea8b 100644
> > --- a/app/test/test_mbuf.c
> > +++ b/app/test/test_mbuf.c
> > @@ -262,8 +262,8 @@ test_one_pktmbuf(struct rte_mempool *pktmbuf_pool)
> > GOTO_FAIL("Buffer should be continuous");
> > memset(hdr, 0x55, MBUF_TEST_HDR2_LEN);
> >
> > - rte_mbuf_sanity_check(m, 1);
> > - rte_mbuf_sanity_check(m, 0);
> > + rte_mbuf_verify(m, 1);
> > + rte_mbuf_verify(m, 0);
> > rte_pktmbuf_dump(stdout, m, 0);
> >
> > /* this prepend should fail */
> > @@ -1162,7 +1162,7 @@ test_refcnt_mbuf(void)
> >
> > #ifdef RTE_EXEC_ENV_WINDOWS
> > static int
> > -test_failing_mbuf_sanity_check(struct rte_mempool *pktmbuf_pool)
> > +test_failing_mbuf_verify(struct rte_mempool *pktmbuf_pool)
> > {
> > RTE_SET_USED(pktmbuf_pool);
> > return TEST_SKIPPED;
> > @@ -1181,12 +1181,12 @@ mbuf_check_pass(struct rte_mbuf *buf)
> > }
> >
> > static int
> > -test_failing_mbuf_sanity_check(struct rte_mempool *pktmbuf_pool)
> > +test_failing_mbuf_verify(struct rte_mempool *pktmbuf_pool)
> > {
> > struct rte_mbuf *buf;
> > struct rte_mbuf badbuf;
> >
> > - printf("Checking rte_mbuf_sanity_check for failure conditions\n");
> > + printf("Checking rte_mbuf_verify for failure conditions\n");
> >
> > /* get a good mbuf to use to make copies */
> > buf = rte_pktmbuf_alloc(pktmbuf_pool);
> > @@ -1708,7 +1708,7 @@ test_mbuf_validate_tx_offload(const char *test_name,
> > GOTO_FAIL("%s: mbuf allocation failed!\n", __func__);
> > if (rte_pktmbuf_pkt_len(m) != 0)
> > GOTO_FAIL("%s: Bad packet length\n", __func__);
> > - rte_mbuf_sanity_check(m, 0);
> > + rte_mbuf_verify(m, 0);
> > m->ol_flags = ol_flags;
> > m->tso_segsz = segsize;
> > ret = rte_validate_tx_offload(m);
> > @@ -1915,7 +1915,7 @@ test_pktmbuf_read(struct rte_mempool *pktmbuf_pool)
> > GOTO_FAIL("%s: mbuf allocation failed!\n", __func__);
> > if (rte_pktmbuf_pkt_len(m) != 0)
> > GOTO_FAIL("%s: Bad packet length\n", __func__);
> > - rte_mbuf_sanity_check(m, 0);
> > + rte_mbuf_verify(m, 0);
> >
> > data = rte_pktmbuf_append(m, MBUF_TEST_DATA_LEN2);
> > if (data == NULL)
> > @@ -1964,7 +1964,7 @@ test_pktmbuf_read_from_offset(struct rte_mempool
> > *pktmbuf_pool)
> >
> > if (rte_pktmbuf_pkt_len(m) != 0)
> > GOTO_FAIL("%s: Bad packet length\n", __func__);
> > - rte_mbuf_sanity_check(m, 0);
> > + rte_mbuf_verify(m, 0);
> >
> > /* prepend an ethernet header */
> > hdr = (struct ether_hdr *)rte_pktmbuf_prepend(m, hdr_len);
> > @@ -2109,7 +2109,7 @@ create_packet(struct rte_mempool *pktmbuf_pool,
> > GOTO_FAIL("%s: mbuf allocation failed!\n", __func__);
> > if (rte_pktmbuf_pkt_len(pkt_seg) != 0)
> > GOTO_FAIL("%s: Bad packet length\n", __func__);
> > - rte_mbuf_sanity_check(pkt_seg, 0);
> > + rte_mbuf_verify(pkt_seg, 0);
> > /* Add header only for the first segment */
> > if (test_data->flags == MBUF_HEADER && seg == 0) {
> > hdr_len = sizeof(struct rte_ether_hdr);
> > @@ -2321,7 +2321,7 @@ test_pktmbuf_ext_shinfo_init_helper(struct rte_mempool
> > *pktmbuf_pool)
> > GOTO_FAIL("%s: mbuf allocation failed!\n", __func__);
> > if (rte_pktmbuf_pkt_len(m) != 0)
> > GOTO_FAIL("%s: Bad packet length\n", __func__);
> > - rte_mbuf_sanity_check(m, 0);
> > + rte_mbuf_verify(m, 0);
> >
> > ext_buf_addr = rte_malloc("External buffer", buf_len,
> > RTE_CACHE_LINE_SIZE);
> > @@ -2482,8 +2482,8 @@ test_pktmbuf_ext_pinned_buffer(struct rte_mempool
> > *std_pool)
> > GOTO_FAIL("%s: test_pktmbuf_copy(pinned) failed\n",
> > __func__);
> >
> > - if (test_failing_mbuf_sanity_check(pinned_pool) < 0)
> > - GOTO_FAIL("%s: test_failing_mbuf_sanity_check(pinned)"
> > + if (test_failing_mbuf_verify(pinned_pool) < 0)
> > + GOTO_FAIL("%s: test_failing_mbuf_verify(pinned)"
> > " failed\n", __func__);
> >
> > if (test_mbuf_linearize_check(pinned_pool) < 0)
> > @@ -2857,8 +2857,8 @@ test_mbuf(void)
> > goto err;
> > }
> >
> > - if (test_failing_mbuf_sanity_check(pktmbuf_pool) < 0) {
> > - printf("test_failing_mbuf_sanity_check() failed\n");
> > + if (test_failing_mbuf_verify(pktmbuf_pool) < 0) {
> > + printf("test_failing_mbuf_verify() failed\n");
> > goto err;
> > }
> >
> > diff --git a/doc/guides/prog_guide/mbuf_lib.rst
> > b/doc/guides/prog_guide/mbuf_lib.rst
> > index 4ad2a21f3f..6c96931f8c 100644
> > --- a/doc/guides/prog_guide/mbuf_lib.rst
> > +++ b/doc/guides/prog_guide/mbuf_lib.rst
> > @@ -266,8 +266,8 @@ can be found in several of the sample applications, for
> > example, the IPv4 Multic
> > Debug
> > -----
> >
> > -In debug mode, the functions of the mbuf library perform sanity checks before
> > any operation (such as, buffer corruption,
> > -bad type, and so on).
> > +In debug mode, the functions of the mbuf library perform consistency checks
> > +before any operation (such as, buffer corruption, bad type, and so on).
> >
> > Use Cases
> > ---------
> > diff --git a/doc/guides/rel_notes/deprecation.rst
> > b/doc/guides/rel_notes/deprecation.rst
> > index 36489f6e68..10bb08a634 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -142,3 +142,6 @@ Deprecation Notices
> > * bus/vmbus: Starting DPDK 25.11, all the vmbus API defined in
> > ``drivers/bus/vmbus/rte_bus_vmbus.h`` will become internal to DPDK.
> > Those API functions are used internally by DPDK core and netvsc PMD.
> > +
> > +* mbuf: The function ``rte_mbuf_sanity_check`` is deprecated.
> > + Use the new function ``rte_mbuf_verify`` instead.
> > diff --git a/lib/mbuf/rte_mbuf.c b/lib/mbuf/rte_mbuf.c
> > index 559d5ad8a7..fc5d4ba29d 100644
> > --- a/lib/mbuf/rte_mbuf.c
> > +++ b/lib/mbuf/rte_mbuf.c
> > @@ -367,9 +367,9 @@ rte_pktmbuf_pool_create_extbuf(const char *name, unsigned
> > int n,
> > return mp;
> > }
> >
> > -/* do some sanity checks on a mbuf: panic if it fails */
> > +/* do some checks on a mbuf: panic if it fails */
> > void
> > -rte_mbuf_sanity_check(const struct rte_mbuf *m, int is_header)
> > +rte_mbuf_verify(const struct rte_mbuf *m, int is_header)
> > {
> > const char *reason;
> >
> > @@ -377,6 +377,13 @@ rte_mbuf_sanity_check(const struct rte_mbuf *m, int
> > is_header)
> > rte_panic("%s\n", reason);
> > }
> >
> > +/* For ABI compatibility, to be removed in next release */
> > +void
> > +rte_mbuf_sanity_check(const struct rte_mbuf *m, int is_header)
> > +{
> > + rte_mbuf_verify(m, is_header);
> > +}
> > +
> > int rte_mbuf_check(const struct rte_mbuf *m, int is_header,
> > const char **reason)
> > {
> > @@ -496,7 +503,7 @@ void rte_pktmbuf_free_bulk(struct rte_mbuf **mbufs,
> > unsigned int count)
> > if (unlikely(m == NULL))
> > continue;
> >
> > - __rte_mbuf_sanity_check(m, 1);
> > + __rte_mbuf_verify(m, 1);
> >
> > do {
> > m_next = m->next;
> > @@ -546,7 +553,7 @@ rte_pktmbuf_clone(struct rte_mbuf *md, struct rte_mempool
> > *mp)
> > return NULL;
> > }
> >
> > - __rte_mbuf_sanity_check(mc, 1);
> > + __rte_mbuf_verify(mc, 1);
> > return mc;
> > }
> >
> > @@ -596,7 +603,7 @@ rte_pktmbuf_copy(const struct rte_mbuf *m, struct
> > rte_mempool *mp,
> > struct rte_mbuf *mc, *m_last, **prev;
> >
> > /* garbage in check */
> > - __rte_mbuf_sanity_check(m, 1);
> > + __rte_mbuf_verify(m, 1);
> >
> > /* check for request to copy at offset past end of mbuf */
> > if (unlikely(off >= m->pkt_len))
> > @@ -660,7 +667,7 @@ rte_pktmbuf_copy(const struct rte_mbuf *m, struct
> > rte_mempool *mp,
> > }
> >
> > /* garbage out check */
> > - __rte_mbuf_sanity_check(mc, 1);
> > + __rte_mbuf_verify(mc, 1);
> > return mc;
> > }
> >
> > @@ -671,7 +678,7 @@ rte_pktmbuf_dump(FILE *f, const struct rte_mbuf *m,
> > unsigned dump_len)
> > unsigned int len;
> > unsigned int nb_segs;
> >
> > - __rte_mbuf_sanity_check(m, 1);
> > + __rte_mbuf_verify(m, 1);
> >
> > fprintf(f, "dump mbuf at %p, iova=%#" PRIx64 ", buf_len=%u\n", m,
> > rte_mbuf_iova_get(m),
> > m->buf_len);
> > @@ -689,7 +696,7 @@ rte_pktmbuf_dump(FILE *f, const struct rte_mbuf *m,
> > unsigned dump_len)
> > nb_segs = m->nb_segs;
> >
> > while (m && nb_segs != 0) {
> > - __rte_mbuf_sanity_check(m, 0);
> > + __rte_mbuf_verify(m, 0);
> >
> > fprintf(f, " segment at %p, data=%p, len=%u, off=%u,
> > refcnt=%u\n",
> > m, rte_pktmbuf_mtod(m, void *),
> > diff --git a/lib/mbuf/rte_mbuf.h b/lib/mbuf/rte_mbuf.h
> > index 06ab7502a5..53a837e4d5 100644
> > --- a/lib/mbuf/rte_mbuf.h
> > +++ b/lib/mbuf/rte_mbuf.h
> > @@ -339,16 +339,20 @@ rte_pktmbuf_priv_flags(struct rte_mempool *mp)
> >
> > #ifdef RTE_LIBRTE_MBUF_DEBUG
> >
> > -/** check mbuf type in debug mode */
> > -#define __rte_mbuf_sanity_check(m, is_h) rte_mbuf_sanity_check(m, is_h)
> > +/** do mbuf type in debug mode */
> > +#define __rte_mbuf_verify(m, is_h) rte_mbuf_verify(m, is_h)
> >
> > #else /* RTE_LIBRTE_MBUF_DEBUG */
> >
> > -/** check mbuf type in debug mode */
> > -#define __rte_mbuf_sanity_check(m, is_h) do { } while (0)
> > +/** ignore mbuf checks if not in debug mode */
> > +#define __rte_mbuf_verify(m, is_h) do { } while (0)
> >
> > #endif /* RTE_LIBRTE_MBUF_DEBUG */
> >
> > +/* deprecated version of the macro */
> > +#define __rte_mbuf_sanity_check(m, is_h)
> > RTE_DEPRECATED(__rte_mbuf_sanity_check) \
> > + __rte_mbuf_verify(m, is_h)
> > +
> > #ifdef RTE_MBUF_REFCNT_ATOMIC
> >
> > /**
> > @@ -514,10 +518,9 @@ rte_mbuf_ext_refcnt_update(struct
> > rte_mbuf_ext_shared_info *shinfo,
> >
> >
> > /**
> > - * Sanity checks on an mbuf.
> > + * Check that the mbuf is valid and panic if corrupted.
> > *
> > - * Check the consistency of the given mbuf. The function will cause a
> > - * panic if corruption is detected.
> > + * Acts assertion that mbuf is consistent. If not it calls rte_panic().
> > *
> > * @param m
> > * The mbuf to be checked.
> > @@ -526,13 +529,17 @@ rte_mbuf_ext_refcnt_update(struct
> > rte_mbuf_ext_shared_info *shinfo,
> > * of a packet (in this case, some fields like nb_segs are not checked)
> > */
> > void
> > +rte_mbuf_verify(const struct rte_mbuf *m, int is_header);
> > +
> > +__rte_deprecated
> > +void
> > rte_mbuf_sanity_check(const struct rte_mbuf *m, int is_header);
> >
> > /**
> > - * Sanity checks on a mbuf.
> > + * Do consistency checks on a mbuf.
> > *
> > - * Almost like rte_mbuf_sanity_check(), but this function gives the reason
> > - * if corruption is detected rather than panic.
> > + * Check the consistency of the given mbuf and if not valid
> > + * return the reason.
> > *
> > * @param m
> > * The mbuf to be checked.
> > @@ -551,7 +558,7 @@ int rte_mbuf_check(const struct rte_mbuf *m, int
> > is_header,
> > const char **reason);
> >
> > /**
> > - * Sanity checks on a reinitialized mbuf in debug mode.
> > + * Do checks on a reinitialized mbuf in debug mode.
> > *
> > * Check the consistency of the given reinitialized mbuf.
> > * The function will cause a panic if corruption is detected.
> > @@ -563,7 +570,7 @@ int rte_mbuf_check(const struct rte_mbuf *m, int
> > is_header,
> > * The mbuf to be checked.
> > */
> > static __rte_always_inline void
> > -__rte_mbuf_raw_sanity_check(__rte_unused const struct rte_mbuf *m)
> > +__rte_mbuf_raw_verify(__rte_unused const struct rte_mbuf *m)
> > {
> > RTE_ASSERT(rte_mbuf_refcnt_read(m) == 1);
> > RTE_ASSERT(m->next == NULL);
> > @@ -572,11 +579,11 @@ __rte_mbuf_raw_sanity_check(__rte_unused const struct
> > rte_mbuf *m)
> > RTE_ASSERT(!RTE_MBUF_HAS_EXTBUF(m) ||
> > (RTE_MBUF_HAS_PINNED_EXTBUF(m) &&
> > rte_mbuf_ext_refcnt_read(m->shinfo) == 1));
> > - __rte_mbuf_sanity_check(m, 0);
> > + __rte_mbuf_verify(m, 0);
> > }
> >
> > /** For backwards compatibility. */
> > -#define MBUF_RAW_ALLOC_CHECK(m) __rte_mbuf_raw_sanity_check(m)
> > +#define MBUF_RAW_ALLOC_CHECK(m) __rte_mbuf_raw_verify(m)
> >
> > /**
> > * Allocate an uninitialized mbuf from mempool *mp*.
> > @@ -606,7 +613,7 @@ static inline struct rte_mbuf *rte_mbuf_raw_alloc(struct
> > rte_mempool *mp)
> >
> > if (rte_mempool_get(mp, &ret.ptr) < 0)
> > return NULL;
> > - __rte_mbuf_raw_sanity_check(ret.m);
> > + __rte_mbuf_raw_verify(ret.m);
> > return ret.m;
> > }
> >
> > @@ -644,7 +651,7 @@ rte_mbuf_raw_alloc_bulk(struct rte_mempool *mp, struct
> > rte_mbuf **mbufs, unsigne
> > int rc = rte_mempool_get_bulk(mp, (void **)mbufs, count);
> > if (likely(rc == 0))
> > for (unsigned int idx = 0; idx < count; idx++)
> > - __rte_mbuf_raw_sanity_check(mbufs[idx]);
> > + __rte_mbuf_raw_verify(mbufs[idx]);
> > return rc;
> > }
> >
> > @@ -665,7 +672,7 @@ rte_mbuf_raw_alloc_bulk(struct rte_mempool *mp, struct
> > rte_mbuf **mbufs, unsigne
> > static __rte_always_inline void
> > rte_mbuf_raw_free(struct rte_mbuf *m)
> > {
> > - __rte_mbuf_raw_sanity_check(m);
> > + __rte_mbuf_raw_verify(m);
> > rte_mempool_put(m->pool, m);
> > }
> >
> > @@ -700,7 +707,7 @@ rte_mbuf_raw_free_bulk(struct rte_mempool *mp, struct
> > rte_mbuf **mbufs, unsigned
> > const struct rte_mbuf *m = mbufs[idx];
> > RTE_ASSERT(m != NULL);
> > RTE_ASSERT(m->pool == mp);
> > - __rte_mbuf_raw_sanity_check(m);
> > + __rte_mbuf_raw_verify(m);
> > }
> >
> > rte_mempool_put_bulk(mp, (void **)mbufs, count);
> > @@ -965,7 +972,7 @@ static inline void rte_pktmbuf_reset(struct rte_mbuf *m)
> > rte_pktmbuf_reset_headroom(m);
> >
> > m->data_len = 0;
> > - __rte_mbuf_sanity_check(m, 1);
> > + __rte_mbuf_verify(m, 1);
> > }
> >
> > /**
> > @@ -1021,22 +1028,22 @@ static inline int rte_pktmbuf_alloc_bulk(struct
> > rte_mempool *pool,
> > switch (count % 4) {
> > case 0:
> > while (idx != count) {
> > - __rte_mbuf_raw_sanity_check(mbufs[idx]);
> > + __rte_mbuf_raw_verify(mbufs[idx]);
> > rte_pktmbuf_reset(mbufs[idx]);
> > idx++;
> > /* fall-through */
> > case 3:
> > - __rte_mbuf_raw_sanity_check(mbufs[idx]);
> > + __rte_mbuf_raw_verify(mbufs[idx]);
> > rte_pktmbuf_reset(mbufs[idx]);
> > idx++;
> > /* fall-through */
> > case 2:
> > - __rte_mbuf_raw_sanity_check(mbufs[idx]);
> > + __rte_mbuf_raw_verify(mbufs[idx]);
> > rte_pktmbuf_reset(mbufs[idx]);
> > idx++;
> > /* fall-through */
> > case 1:
> > - __rte_mbuf_raw_sanity_check(mbufs[idx]);
> > + __rte_mbuf_raw_verify(mbufs[idx]);
> > rte_pktmbuf_reset(mbufs[idx]);
> > idx++;
> > /* fall-through */
> > @@ -1267,8 +1274,8 @@ static inline void rte_pktmbuf_attach(struct rte_mbuf
> > *mi, struct rte_mbuf *m)
> > mi->pkt_len = mi->data_len;
> > mi->nb_segs = 1;
> >
> > - __rte_mbuf_sanity_check(mi, 1);
> > - __rte_mbuf_sanity_check(m, 0);
> > + __rte_mbuf_verify(mi, 1);
> > + __rte_mbuf_verify(m, 0);
> > }
> >
> > /**
> > @@ -1423,7 +1430,7 @@ static inline int
> > __rte_pktmbuf_pinned_extbuf_decref(struct rte_mbuf *m)
> > static __rte_always_inline struct rte_mbuf *
> > rte_pktmbuf_prefree_seg(struct rte_mbuf *m)
> > {
> > - __rte_mbuf_sanity_check(m, 0);
> > + __rte_mbuf_verify(m, 0);
> >
> > if (likely(rte_mbuf_refcnt_read(m) == 1)) {
> >
> > @@ -1494,7 +1501,7 @@ static inline void rte_pktmbuf_free(struct rte_mbuf *m)
> > struct rte_mbuf *m_next;
> >
> > if (m != NULL)
> > - __rte_mbuf_sanity_check(m, 1);
> > + __rte_mbuf_verify(m, 1);
> >
> > while (m != NULL) {
> > m_next = m->next;
> > @@ -1575,7 +1582,7 @@ rte_pktmbuf_copy(const struct rte_mbuf *m, struct
> > rte_mempool *mp,
> > */
> > static inline void rte_pktmbuf_refcnt_update(struct rte_mbuf *m, int16_t v)
> > {
> > - __rte_mbuf_sanity_check(m, 1);
> > + __rte_mbuf_verify(m, 1);
> >
> > do {
> > rte_mbuf_refcnt_update(m, v);
> > @@ -1592,7 +1599,7 @@ static inline void rte_pktmbuf_refcnt_update(struct
> > rte_mbuf *m, int16_t v)
> > */
> > static inline uint16_t rte_pktmbuf_headroom(const struct rte_mbuf *m)
> > {
> > - __rte_mbuf_sanity_check(m, 0);
> > + __rte_mbuf_verify(m, 0);
> > return m->data_off;
> > }
> >
> > @@ -1606,7 +1613,7 @@ static inline uint16_t rte_pktmbuf_headroom(const struct
> > rte_mbuf *m)
> > */
> > static inline uint16_t rte_pktmbuf_tailroom(const struct rte_mbuf *m)
> > {
> > - __rte_mbuf_sanity_check(m, 0);
> > + __rte_mbuf_verify(m, 0);
> > return (uint16_t)(m->buf_len - rte_pktmbuf_headroom(m) -
> > m->data_len);
> > }
> > @@ -1621,7 +1628,7 @@ static inline uint16_t rte_pktmbuf_tailroom(const struct
> > rte_mbuf *m)
> > */
> > static inline struct rte_mbuf *rte_pktmbuf_lastseg(struct rte_mbuf *m)
> > {
> > - __rte_mbuf_sanity_check(m, 1);
> > + __rte_mbuf_verify(m, 1);
> > while (m->next != NULL)
> > m = m->next;
> > return m;
> > @@ -1665,7 +1672,7 @@ static inline struct rte_mbuf
> > *rte_pktmbuf_lastseg(struct rte_mbuf *m)
> > static inline char *rte_pktmbuf_prepend(struct rte_mbuf *m,
> > uint16_t len)
> > {
> > - __rte_mbuf_sanity_check(m, 1);
> > + __rte_mbuf_verify(m, 1);
> >
> > if (unlikely(len > rte_pktmbuf_headroom(m)))
> > return NULL;
> > @@ -1700,7 +1707,7 @@ static inline char *rte_pktmbuf_append(struct rte_mbuf
> > *m, uint16_t len)
> > void *tail;
> > struct rte_mbuf *m_last;
> >
> > - __rte_mbuf_sanity_check(m, 1);
> > + __rte_mbuf_verify(m, 1);
> >
> > m_last = rte_pktmbuf_lastseg(m);
> > if (unlikely(len > rte_pktmbuf_tailroom(m_last)))
> > @@ -1728,7 +1735,7 @@ static inline char *rte_pktmbuf_append(struct rte_mbuf
> > *m, uint16_t len)
> > */
> > static inline char *rte_pktmbuf_adj(struct rte_mbuf *m, uint16_t len)
> > {
> > - __rte_mbuf_sanity_check(m, 1);
> > + __rte_mbuf_verify(m, 1);
> >
> > if (unlikely(len > m->data_len))
> > return NULL;
> > @@ -1760,7 +1767,7 @@ static inline int rte_pktmbuf_trim(struct rte_mbuf *m,
> > uint16_t len)
> > {
> > struct rte_mbuf *m_last;
> >
> > - __rte_mbuf_sanity_check(m, 1);
> > + __rte_mbuf_verify(m, 1);
> >
> > m_last = rte_pktmbuf_lastseg(m);
> > if (unlikely(len > m_last->data_len))
> > @@ -1782,7 +1789,7 @@ static inline int rte_pktmbuf_trim(struct rte_mbuf *m,
> > uint16_t len)
> > */
> > static inline int rte_pktmbuf_is_contiguous(const struct rte_mbuf *m)
> > {
> > - __rte_mbuf_sanity_check(m, 1);
> > + __rte_mbuf_verify(m, 1);
> > return m->nb_segs == 1;
> > }
> >
> > diff --git a/lib/mbuf/version.map b/lib/mbuf/version.map
> > index 76f1832924..2950f24caa 100644
> > --- a/lib/mbuf/version.map
> > +++ b/lib/mbuf/version.map
> > @@ -31,6 +31,7 @@ DPDK_25 {
> > rte_mbuf_set_platform_mempool_ops;
> > rte_mbuf_set_user_mempool_ops;
> > rte_mbuf_user_mempool_ops;
> > + rte_mbuf_verify;
> > rte_pktmbuf_clone;
> > rte_pktmbuf_copy;
> > rte_pktmbuf_dump;
> > --
> > 2.47.2
>
> Stephen,
>
> I have submitted another patch [1], where __rte_mbuf_raw_sanity_check()'s successor takes one more parameter, so I had to give it a new name __rte_mbuf_raw_sanity_check_mp() for API compatibility. And then I added:
> +/** For backwards compatibility. */
> +#define __rte_mbuf_raw_sanity_check(m) __rte_mbuf_raw_sanity_check_mp(m, NULL)
>
> If you proceed with your patch, __rte_mbuf_raw_sanity_check() will be renamed to __rte_mbuf_raw_verify(), and __rte_mbuf_raw_sanity_check() disappears.
> Would it make sense to change your patch, so __rte_mbuf_raw_verify() replaces __rte_mbuf_raw_sanity_check_mp() instead of __rte_mbuf_raw_sanity_check()? If your patch changes the API anyway, adding an extra parameter to the function should be acceptable.
>
> [1]: https://patchwork.dpdk.org/project/dpdk/patch/20250722093431.555214-1-mb@smartsharesystems.com/
Sure will go back and rebase old patches in a few weeks.
^ permalink raw reply [relevance 0%]
* Re: [EXTERNAL] [PATCH] doc: announce DMA configuration structure changes
2025-07-28 5:11 4% ` Pavan Nikhilesh Bhagavatula
@ 2025-08-12 10:59 0% ` Thomas Monjalon
0 siblings, 0 replies; 15+ results
From: Thomas Monjalon @ 2025-08-12 10:59 UTC (permalink / raw)
To: Pavan Nikhilesh Bhagavatula
Cc: fengchengwen, techboard, Amit Prakash Shukla, dev, Jerin Jacob,
Vamsi Krishna Attunuru, g.singh, sachin.saxena, hemant.agrawal,
bruce.richardson, kevin.laatz, conor.walsh,
Gowrishankar Muthukrishnan, Vidya Sagar Velumuri,
anatoly.burakov
28/07/2025 07:11, Pavan Nikhilesh Bhagavatula:
> >Acked-by: Chengwen Feng <fengchengwen@huawei.com>
> >
>
> Thomas,
>
> Now that Feng Chengwen is ok with this change, can this be merged
> along with the ABI breaking changes in 25.11?
> Given that techboard approves the change.
> This change helps reduce ABI breakage when a new feature is added.
I would be in favor of this change.
Let's request a vote in the next techboard meeting.
(Cc techboard@dpdk.org and added in the meeting agenda)
> >On 2025/7/25 14:04, Pavan Nikhilesh Bhagavatula wrote:
> >>>> Deprecate rte_dma_conf structure to allow for a more flexible
> >>>> configuration of DMA devices.
> >>>> The new structure will have a flags field instead of multiple
> >>>> boolean fields for each feature.
> >>>>
> >>>> Signed-off-by: Pavan Nikhilesh <mailto:pbhagavatula@marvell.com>
> >>>> ---
> >>>> +* dmadev: The ``rte_dma_conf`` structure is updated to include a new field
> >>>> + ``rte_dma_conf::flags`` that should be used to configure dmadev features.
> >>>> + The existing field ``rte_dma_conf::enable_silent`` is removed and replaced
> >>>> + with the new flag ``RTE_DMA_CFG_FLAG_SILENT``, to configure silent mode
> >>>> + the flag should be set in ``rte_dma_conf::flags`` during device configuration.
> >>>>
> >>>> Acked-by: Amit Prakash Shukla <amitprakashs@marvell.com>
> >>>
> >>> There is only 1 ack.
> >>> Per our policy, it will miss the release 25.07.
> >>>
> >>> You can probably do this change anyway,
> >>> and keep ABI compatibility by versioning the function.
> >>
> >> Hi Fengchengwen,
> >>
> >> Are you ok with this change? If so please ack it so that I can work on getting
> >> an exception from techboard to merge this without deprecation notice in 25.11.
> >>
> >> Thanks,
> >> Pavan.
^ permalink raw reply [relevance 0%]
* RE: [EXTERNAL] Re: [PATCH v2 1/1] ethdev: add support to provide link type
@ 2025-08-13 7:42 4% ` Sunil Kumar Kori
0 siblings, 0 replies; 15+ results
From: Sunil Kumar Kori @ 2025-08-13 7:42 UTC (permalink / raw)
To: Morten Brørup, Stephen Hemminger
Cc: Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko, dev,
Nithin Kumar Dabilpuram, Jerin Jacob
Hi Morten and Stephen,
To address your comments, I revisited to change and concluded following points:
1. Extending Link Types Alongside Legacy:
I'm aligned on extending link types while retaining legacy support — No concerns here. I will add following link type to the list.
- NONE
- TP
- AUI
- MII
- FIBRE
- BNC
- DA
- SGMII
- QSGMII
- XFI
- SFI
- XLAUI
- GAUI
- SFI
- XAUI
- XLAUI
- GAUI
- GBASE
- CAUI
- LAUI
- SFP
- SFP_DD
- SFP_PLUS
- SFP28
- QSFP
- QSFP_PLUS
- QSFP28
- QSFP56
- QSFP_DD
- OTHER
2. ABI Breakage Concern:
"I'm not entirely clear on how this change results in an ABI breakage, as the new bit field is added within the existing space. Could you please elaborate on the specific aspects that lead to ABI incompatibility ?" Worst case, since this is 25.11, API breakage is fine.
3. Reporting Link Type by Drivers:
General APIs often expose capabilities, and drivers selectively implement them. Setting the link type to 0 when unsupported is a reasonable fallback.
Ensuring 0 is treated as “unknown” or “not supported” rather than misleading.
4. Regarding management interfaces for PHYs or modules:
This patch does not introduce any management APIs for PHYs or modules. Its sole purpose is to expose the link type as an additional attribute to the user. Any support for PHY or module management should be handled separately and is outside the scope of this change.
Thanks
Sunil Kumar Kori
> > From: Sunil Kumar Kori [mailto:skori@marvell.com]
> > Sent: Tuesday, 10 June 2025 07.02
> >
> > > On Fri, 6 Jun 2025 11:54:52 +0200
> > > Morten Brørup <mb@smartsharesystems.com> wrote:
> > >
> > > > > From: skori@marvell.com [mailto:skori@marvell.com]
> > > > > Sent: Friday, 6 June 2025 11.28
> > > > >
> > > > > From: Sunil Kumar Kori <skori@marvell.com>
> > > > >
> > > > > Adding link type parameter to provide the type of port like
> > > > > twisted pair, fibre etc.
> > > > >
> > > > > Also added an API to convert the RTE_ETH_LINK_TYPE_XXX to a
> > > > > readable string.
> > > > >
> > > > > Signed-off-by: Nithin Dabilpuram <ndabilpuram@marvell.com>
> > > > > Signed-off-by: Sunil Kumar Kori <skori@marvell.com>
> > > > > ---
> > > > > +/**@{@name PORT type
> > > > > + * Ethernet port type
> > > > > + */
> > > > > +#define RTE_ETH_LINK_TYPE_NONE 0x00 /**< Not defined */
> > > > > +#define RTE_ETH_LINK_TYPE_TP 0x01 /**< Twisted Pair */
> > > > > +#define RTE_ETH_LINK_TYPE_AUI 0x02 /**< Attachment Unit Interface */
> > > > > +#define RTE_ETH_LINK_TYPE_MII 0x03 /**< Media Independent Interface
> > > > > */
> > > > > +#define RTE_ETH_LINK_TYPE_FIBRE 0x04 /**< Fibre */
> > > > > +#define RTE_ETH_LINK_TYPE_BNC 0x05 /**< BNC */
> > > > > +#define RTE_ETH_LINK_TYPE_DA 0x06 /**< Direct Attach copper */
> > > > > +#define RTE_ETH_LINK_TYPE_OTHER 0x1F /**< Other type */ /**@}*/
> > > >
^ permalink raw reply [relevance 4%]
* RE: [EXTERNAL] Re: [PATCH v0 1/1] doc: announce inter-device DMA capability support in dmadev
@ 2025-08-13 16:46 3% ` Vamsi Krishna Attunuru
2025-08-14 0:44 0% ` fengchengwen
0 siblings, 1 reply; 15+ results
From: Vamsi Krishna Attunuru @ 2025-08-13 16:46 UTC (permalink / raw)
To: fengchengwen, thomas
Cc: Jerin Jacob, thomas, dev, Pavan Nikhilesh Bhagavatula,
kevin.laatz, bruce.richardson, Vladimir Medvedkin,
Anatoly Burakov, Vamsi Krishna Attunuru, techboard
Hi Thomas, Feng
Can this feature be discussed in the next techboard meeting and decide on supporting it
together with the ABI breaking changes in 25.11, rather than using the versions scheme.
Since there are no further comments after we aligned with the Feng's feedback, it would be
good to finalize the approach.
Regards
Vamsi
>-----Original Message-----
>From: Vamsi Krishna Attunuru <vattunuru@marvell.com>
>Sent: Wednesday, July 30, 2025 10:07 AM
>To: fengchengwen <fengchengwen@huawei.com>;
>bruce.richardson@intel.com; Vladimir Medvedkin
><vladimir.medvedkin@intel.com>; Anatoly Burakov
><anatoly.burakov@intel.com>
>Cc: Jerin Jacob <jerinj@marvell.com>; thomas@monjalon.net;
>dev@dpdk.org; Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>;
>kevin.laatz@intel.com
>Subject: RE: [EXTERNAL] Re: [PATCH v0 1/1] doc: announce inter-device DMA
>capability support in dmadev
>
>Gentle reminder to share your feedback. >Hi Bruce, Vladimir, Anatoly >
>>Regarding inter-device or inter-domain DMA capability, could please clarify if
>>Intel idxd driver will support this feature. >I believe the changes Feng has
>ZjQcmQRYFpfptBannerStart Prioritize security for external emails:
>Confirm sender and content safety before clicking links or opening
>attachments <https://us-phishalarm-
>ewt.proofpoint.com/EWT/v1/CRVmXkqW!uq3V-
>r_YrnsUWi9yeT3UAKXL4FFc4ONZAyvoCMlneUv-fN8An8AKohi4aES-
>ZG37anFsJG5Rq3NspRNGjPgt5I9U4c9cEVeu_P4sHAEFMopboItEI9hkXOMUrJ
>m_Pyoic-gg6kRF3p9wjJrTGA$>
>Report Suspicious
>
>ZjQcmQRYFpfptBannerEnd
>Gentle reminder to share your feedback.
>
>>Hi Bruce, Vladimir, Anatoly
>>
>>Regarding inter-device or inter-domain DMA capability, could please
>>clarify if Intel idxd driver will support this feature.
>>I believe the changes Feng has suggested here are in line with the
>>earlier "[PATCH v1 0/3] Add support for inter-domain DMA operations"
>>proposal. We are planning to implement this feature support in version
>25.11.
>>
>>Your feedback would be appreciated, we are aiming for a more generic
>>solution.
>>
>>Regards
>>Vamsi
>>
>>
>>>>On 2025/7/16 18:59, Vamsi Krishna Attunuru wrote:
>>>>>
>>>>>>
>>>>>> Thanks for the explanation.
>>>>>>
>>>>>> Let me tell you what I understand:
>>>>>> 1\ Two dmadev (must belong to the same DMA controller?) each
>>>>>> passthrough to diffent domain (VM or container) 2\ The kernel DMA
>>>>>> controller driver could config access groups --- there is a secure
>>>>>> mechanism
>>>>(like Intel IDPTE)
>>>>>> and the two dmadev could communicate if the kernel DMA
>>>>>> controller driver has put them in the same access groups.
>>>>>> 3\ Application setup access group and get handle (maybe the new
>>>>'dev_idx'
>>>>>> which you announce in this commit),
>>>>>> and then setup one vchan which config the handle.
>>>>>> and later launch copy request based on this vchan.
>>>>>> 4\ The driver will pass the request to dmadev-1 hardware, and
>>>>>> dmadev-1 hardware will do some verification,
>>>>>> and maybe use dmadev-2 stream ID for read/write operations?
>>>>>>
>>>>>> A few question about this:
>>>>>> 1\ What the prototype of 'dev_idx', is it uint16_t?
>>>>> Yes, it can be uint16_t and use two different dev_idx (src_dev_idx
>>>>> &
>>>>> dest_dev_idx) for read & write.
>>>>>
>>>>>> 2\ How to implement read/write between two dmadev ? use two
>>>>>> different dev_idx? the first for read and the second for write?
>>>>> Yes, two different dev_idx will be used.
>>>>>
>>>>>>
>>>>>>
>>>>>> I also re-read the patchset "[PATCH v1 0/3] Add support for
>>>>>> inter-domain DMA operations", it introduce:
>>>>>> 1\ One 'int controller-id' in the rte_dma_info. which maybe used
>>>>>> in
>>>>>> vendor- specific secure mechanism.
>>>>>> 2\ Two new OP_flag and two new datapath API.
>>>>>> The reason why this patch didn't continue (I guess) is whether
>>>>>> setup one new vchan. Yes, vchan was designed to represents
>>>>>> different transfer contexts. But each vchan has its own
>>>>>> enqueue/dequeue/ring, it more act like one logic dmadev, some of
>>>>>> the hardware can fit this model well, some may not (like Intel in
>>>>>> this
>>case).
>>>>>>
>>>>>>
>>>>>> So how about the following scheme:
>>>>>> 1\ Add inter-domain capability bits, for example:
>>>>>> RTE_DMA_CAPA_INTER_PROCESS_DOMAIN,
>>>>>> RTE_DMA_CAPA_INTER_OS_DOMAIN 2\ Add one
>domain_controller_id
>>>in
>>>>the
>>>>>> rte_dma_info which maybe used in vendor-specific secure
>mechanism.
>>>>>> 3\ Add four OP_FLAGs:
>>>>>> RTE_DMA_OP_FLAG_SRC_INTER_PROCESS_DOMAIN_HANDLE,
>>>>>> RTE_DMA_OP_FLAG_DST_INTER_PROCESS_DOMAIN_HANDLE
>>>>>> RTE_DMA_OP_FLAG_SRC_INTER_OS_DOMAIN_HANDLE,
>>>>>> RTE_DMA_OP_FLAG_DST_INTER_OS_DOMAIN_HANDLE
>>>>>> 4\ Reserved 32bit from flag parameter (which all enqueue API both
>>>>>> supports) as the src and dst handle.
>>>>>> or only reserved 16bit from flag parameter if we restrict don't
>>>>>> support 3rd transfer.
>>>>>
>>>>> Yes, the above approach seems acceptable to me. I believe src & dst
>>>>> handles require 16-bit values. Reserving 32-bits from flag
>>>>> parameter would leave 32 flags available, which should be fine.
>>>>
>>>>Great
>>>>tip: there are still 24bit flag reserved after apply this scheme.
>>>>
>>>>Would like more comments.
>>>>
>>>
>>>If there are no major comments at this time, can we proceed with
>>>accepting and merging this notice in this release. Further review can
>>>continue once the RFC is available next month.
>>>
>>>Thanks & Regards
>>>Vamsi
>>>
>>>>>
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> On 2025/7/15 13:35, Vamsi Krishna Attunuru wrote:
>>>>>>> Hi Feng,
>>>>>>>
>>>>>>> Thanks for depicting the feature use case.
>>>>>>>
>>>>>>> From the application’s perspective, inter VM/process
>>>>>>> communication is
>>>>>> required to exchange the src & dst buffer details, however the
>>>>>> specifics of this communication mechanism are outside the scope in
>>>>>> this context. Regarding the address translations, these buffer
>>>>>> addresses can be either IOVA as PA or IOVA as VA. The DMA hardware
>>>>>> must use the appropriate IOMMU stream IDs when initiating the DMA
>>>>>> transfers. For example, in the use case shown in the diagram,
>>>>>> dmadev-1 and dmadev-2 would join an access group managed by the
>>>>>> kernel DMA controller driver. This controller driver will
>>>>>> configure the access group on the DMA hardware, enabling the
>>>>>> hardware to select the correct stream IDs for read/write
>>>>>> operations. New rte_dma APIs could be introduced to join or leave
>>>>>> the access group or to query the access group details.
>>>>>> Additionally, a secure token mechanism (similar to
>>>>vfio-pci token) can be implemented to validate any dmadev attempting
>>>>to join the access group.
>>>>>>>
>>>>>>> Regards.
>>>>>>>
>>>>>>> From: fengchengwen <fengchengwen@huawei.com>
>>>>>>> Sent: Tuesday, July 15, 2025 6:29 AM
>>>>>>> To: Vamsi Krishna Attunuru <vattunuru@marvell.com>;
>>dev@dpdk.org;
>>>>>>> Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>;
>>>>>>> kevin.laatz@intel.com; bruce.richardson@intel.com;
>>>>>>> mb@smartsharesystems.com
>>>>>>> Cc: Jerin Jacob <jerinj@marvell.com>; thomas@monjalon.net
>>>>>>> Subject: [EXTERNAL] Re: [PATCH v0 1/1] doc: announce inter-device
>>>>>>> DMA capability support in dmadev
>>>>>>>
>>>>>>> Hi Vamsi, From the commit log, I guess this commit mainly want to
>>>>>>> meet following case: --------------- ---------------- | Container
>>>>>>> |
>>>>>>> | VirtMachine | | | | | | dmadev-1 | | dmadev2 | ---------------
>>>>>>> ---------------- |
>>>>>> | ------------------------------ ZjQcmQRYFpfptBannerStart
>>>>>> | Prioritize security for
>>>>>> external emails:
>>>>>>> Confirm sender and content safety before clicking links or
>>>>>>> opening
>>>>>> attachments
>>>>>>> Report Suspicious
>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__us-
>>>2Dphishala
>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__us-
>>>>>>> >>2Dphishala >>>>>>> r
>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__us-
>>>2Dphishala
>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__us-
>>>>>>> >>2Dphishala >>>>>>> r >>>>> m-
>>>>2D&d=DwIDaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=WllrYaumVkxaWjgKto6
>E
>>_r
>>>t
>>>>DQsh
>>>>>>>
>>>>hIhik2jkvzFyRhW8&m=3uFGFVHxC4YLkjWHNg9s9rNDHd_ozbhLepOYCAki
>Z
>>K
>>>x
>>>>M0sQ0m
>>>>>>>
>>>>43gqgTQl1cK9koZ&s=3_mvLYuMWu7RbHD3mj21CP65O5JY8L8AK8oVFutdT
>>W
>>>U
>>>>&e=
>>>>>>
>>>>ewt.proofpoint.com/EWT/v1/CRVmXkqW!tg3ZldV0Yr_wdSwWmT2aDdK
>Mi
>>-
>>>>>>
>>>>4rn2z58vFaxwfOeocS1P19w1BeRdyGs5sjnhV2rU_6m8MOWj4KFbuXKkKJI
>v
>>c
>>>q
>>>>>> wWD2WEwJW_0$ >
>>>>>>> ZjQcmQRYFpfptBannerEnd
>>>>>>>
>>>>>>> Hi Vamsi,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From the commit log, I guess this commit mainly want to meet
>>>>>>> following
>>>>>> case:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --------------- ----------------
>>>>>>>
>>>>>>> | Container | | VirtMachine |
>>>>>>>
>>>>>>> | | | |
>>>>>>>
>>>>>>> | dmadev-1 | | dmadev2 |
>>>>>>>
>>>>>>> --------------- ----------------
>>>>>>>
>>>>>>> | |
>>>>>>>
>>>>>>> ------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> App run in the container could launch DMA transfer from local
>>>>>>> buffer to the VirtMachine by config
>>>>>>>
>>>>>>> dmadev-1/2 (the dmadev-1/2 are passthrough to diffent OS domain).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Could you explain how to use it from application perspective (for
>>>>>>> example address translation) and
>>>>>>>
>>>>>>> application & hardware restrictions?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> BTW: In this case, there are two OS domain communication, and I
>>>>>>> remember there are also inter-process
>>>>>>>
>>>>>>> DMA RFC, so maybe we could design more generic solution if you
>>>>>>> provide
>>>>>> more info.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2025/7/10 16:51, Vamsi Krishna wrote:
>>>>>>>
>>>>>>>> From: Vamsi Attunuru
>>>>>>>> <vattunuru@marvell.com<mailto:vattunuru@marvell.com>>
>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>> Modern DMA hardware supports data transfer between multiple
>>>>>>>
>>>>>>>> DMA devices, enabling data communication across isolated domains
>>>>>>>> or
>>>>>>>
>>>>>>>> containers. To facilitate this, the ``dmadev`` library requires
>>>>>>>> changes
>>>>>>>
>>>>>>>> to allow devices to register with or unregisters from DMA groups
>>>>>>>> for
>>>>>>>
>>>>>>>> inter-device communication. This feature is planned for
>>>>>>>> inclusion
>>>>>>>
>>>>>>>> in DPDK 25.11.
>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>> Signed-off-by: Vamsi Attunuru
>>>>>>>> <vattunuru@marvell.com<mailto:vattunuru@marvell.com>>
>>>>>>>
>>>>>>>> ---
>>>>>>>
>>>>>>>> doc/guides/rel_notes/deprecation.rst | 7 +++++++
>>>>>>>
>>>>>>>> 1 file changed, 7 insertions(+)
>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>> diff --git a/doc/guides/rel_notes/deprecation.rst
>>>>>>>> b/doc/guides/rel_notes/deprecation.rst
>>>>>>>
>>>>>>>> index e2d4125308..46836244dd 100644
>>>>>>>
>>>>>>>> --- a/doc/guides/rel_notes/deprecation.rst
>>>>>>>
>>>>>>>> +++ b/doc/guides/rel_notes/deprecation.rst
>>>>>>>
>>>>>>>> @@ -152,3 +152,10 @@ Deprecation Notices
>>>>>>>
>>>>>>>> * bus/vmbus: Starting DPDK 25.11, all the vmbus API defined in
>>>>>>>
>>>>>>>> ``drivers/bus/vmbus/rte_bus_vmbus.h`` will become internal to
>>>DPDK.
>>>>>>>
>>>>>>>> Those API functions are used internally by DPDK core and
>>>>>>>> netvsc
>>>PMD.
>>>>>>>
>>>>>>>> +
>>>>>>>
>>>>>>>> +* dmadev: a new capability flag ``RTE_DMA_CAPA_INTER_DEV``
>will
>>>>>>>> +be added
>>>>>>>
>>>>>>>> + to advertise DMA device's inter-device DMA copy capability.
>>>>>>>> + To enable
>>>>>>>
>>>>>>>> + this functionality, a few dmadev APIs will be added to
>>>>>>>> + configure the DMA
>>>>>>>
>>>>>>>> + access groups, facilitating coordinated data communication
>>>>>>>> + between
>>>>>> devices.
>>>>>>>
>>>>>>>> + A new ``dev_idx`` field will be added to the ``struct
>>>>>>>> + rte_dma_vchan_conf``
>>>>>>>
>>>>>>>> + structure to configure a vchan for data transfers between any
>>>>>>>> + two DMA
>>>>>> devices.
>>>>>>>
>>>>>>>
>>>>>
^ permalink raw reply [relevance 3%]
* Re: [EXTERNAL] Re: [PATCH v0 1/1] doc: announce inter-device DMA capability support in dmadev
2025-08-13 16:46 3% ` Vamsi Krishna Attunuru
@ 2025-08-14 0:44 0% ` fengchengwen
0 siblings, 0 replies; 15+ results
From: fengchengwen @ 2025-08-14 0:44 UTC (permalink / raw)
To: Vamsi Krishna Attunuru, thomas
Cc: Jerin Jacob, dev, Pavan Nikhilesh Bhagavatula, kevin.laatz,
bruce.richardson, Vladimir Medvedkin, Anatoly Burakov, techboard
I agree the feature discussed in TB.
The original scheme is too vague and hard to understand, although after several round of clarification.
On 8/14/2025 12:46 AM, Vamsi Krishna Attunuru wrote:
> Hi Thomas, Feng
>
> Can this feature be discussed in the next techboard meeting and decide on supporting it
> together with the ABI breaking changes in 25.11, rather than using the versions scheme.
> Since there are no further comments after we aligned with the Feng's feedback, it would be
> good to finalize the approach.
>
> Regards
> Vamsi
>
>> -----Original Message-----
>> From: Vamsi Krishna Attunuru <vattunuru@marvell.com>
>> Sent: Wednesday, July 30, 2025 10:07 AM
>> To: fengchengwen <fengchengwen@huawei.com>;
>> bruce.richardson@intel.com; Vladimir Medvedkin
>> <vladimir.medvedkin@intel.com>; Anatoly Burakov
>> <anatoly.burakov@intel.com>
>> Cc: Jerin Jacob <jerinj@marvell.com>; thomas@monjalon.net;
>> dev@dpdk.org; Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>;
>> kevin.laatz@intel.com
>> Subject: RE: [EXTERNAL] Re: [PATCH v0 1/1] doc: announce inter-device DMA
>> capability support in dmadev
>>
>> Gentle reminder to share your feedback. >Hi Bruce, Vladimir, Anatoly >
>>> Regarding inter-device or inter-domain DMA capability, could please clarify if
>>> Intel idxd driver will support this feature. >I believe the changes Feng has
>> ZjQcmQRYFpfptBannerStart Prioritize security for external emails:
>> Confirm sender and content safety before clicking links or opening
>> attachments <https://us-phishalarm-
>> ewt.proofpoint.com/EWT/v1/CRVmXkqW!uq3V-
>> r_YrnsUWi9yeT3UAKXL4FFc4ONZAyvoCMlneUv-fN8An8AKohi4aES-
>> ZG37anFsJG5Rq3NspRNGjPgt5I9U4c9cEVeu_P4sHAEFMopboItEI9hkXOMUrJ
>> m_Pyoic-gg6kRF3p9wjJrTGA$>
>> Report Suspicious
>>
>> ZjQcmQRYFpfptBannerEnd
>> Gentle reminder to share your feedback.
>>
>>> Hi Bruce, Vladimir, Anatoly
>>>
>>> Regarding inter-device or inter-domain DMA capability, could please
>>> clarify if Intel idxd driver will support this feature.
>>> I believe the changes Feng has suggested here are in line with the
>>> earlier "[PATCH v1 0/3] Add support for inter-domain DMA operations"
>>> proposal. We are planning to implement this feature support in version
>> 25.11.
>>>
>>> Your feedback would be appreciated, we are aiming for a more generic
>>> solution.
>>>
>>> Regards
>>> Vamsi
>>>
>>>
>>>>> On 2025/7/16 18:59, Vamsi Krishna Attunuru wrote:
>>>>>>
>>>>>>>
>>>>>>> Thanks for the explanation.
>>>>>>>
>>>>>>> Let me tell you what I understand:
>>>>>>> 1\ Two dmadev (must belong to the same DMA controller?) each
>>>>>>> passthrough to diffent domain (VM or container) 2\ The kernel DMA
>>>>>>> controller driver could config access groups --- there is a secure
>>>>>>> mechanism
>>>>> (like Intel IDPTE)
>>>>>>> and the two dmadev could communicate if the kernel DMA
>>>>>>> controller driver has put them in the same access groups.
>>>>>>> 3\ Application setup access group and get handle (maybe the new
>>>>> 'dev_idx'
>>>>>>> which you announce in this commit),
>>>>>>> and then setup one vchan which config the handle.
>>>>>>> and later launch copy request based on this vchan.
>>>>>>> 4\ The driver will pass the request to dmadev-1 hardware, and
>>>>>>> dmadev-1 hardware will do some verification,
>>>>>>> and maybe use dmadev-2 stream ID for read/write operations?
>>>>>>>
>>>>>>> A few question about this:
>>>>>>> 1\ What the prototype of 'dev_idx', is it uint16_t?
>>>>>> Yes, it can be uint16_t and use two different dev_idx (src_dev_idx
>>>>>> &
>>>>>> dest_dev_idx) for read & write.
>>>>>>
>>>>>>> 2\ How to implement read/write between two dmadev ? use two
>>>>>>> different dev_idx? the first for read and the second for write?
>>>>>> Yes, two different dev_idx will be used.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I also re-read the patchset "[PATCH v1 0/3] Add support for
>>>>>>> inter-domain DMA operations", it introduce:
>>>>>>> 1\ One 'int controller-id' in the rte_dma_info. which maybe used
>>>>>>> in
>>>>>>> vendor- specific secure mechanism.
>>>>>>> 2\ Two new OP_flag and two new datapath API.
>>>>>>> The reason why this patch didn't continue (I guess) is whether
>>>>>>> setup one new vchan. Yes, vchan was designed to represents
>>>>>>> different transfer contexts. But each vchan has its own
>>>>>>> enqueue/dequeue/ring, it more act like one logic dmadev, some of
>>>>>>> the hardware can fit this model well, some may not (like Intel in
>>>>>>> this
>>> case).
>>>>>>>
>>>>>>>
>>>>>>> So how about the following scheme:
>>>>>>> 1\ Add inter-domain capability bits, for example:
>>>>>>> RTE_DMA_CAPA_INTER_PROCESS_DOMAIN,
>>>>>>> RTE_DMA_CAPA_INTER_OS_DOMAIN 2\ Add one
>> domain_controller_id
>>>> in
>>>>> the
>>>>>>> rte_dma_info which maybe used in vendor-specific secure
>> mechanism.
>>>>>>> 3\ Add four OP_FLAGs:
>>>>>>> RTE_DMA_OP_FLAG_SRC_INTER_PROCESS_DOMAIN_HANDLE,
>>>>>>> RTE_DMA_OP_FLAG_DST_INTER_PROCESS_DOMAIN_HANDLE
>>>>>>> RTE_DMA_OP_FLAG_SRC_INTER_OS_DOMAIN_HANDLE,
>>>>>>> RTE_DMA_OP_FLAG_DST_INTER_OS_DOMAIN_HANDLE
>>>>>>> 4\ Reserved 32bit from flag parameter (which all enqueue API both
>>>>>>> supports) as the src and dst handle.
>>>>>>> or only reserved 16bit from flag parameter if we restrict don't
>>>>>>> support 3rd transfer.
>>>>>>
>>>>>> Yes, the above approach seems acceptable to me. I believe src & dst
>>>>>> handles require 16-bit values. Reserving 32-bits from flag
>>>>>> parameter would leave 32 flags available, which should be fine.
>>>>>
>>>>> Great
>>>>> tip: there are still 24bit flag reserved after apply this scheme.
>>>>>
>>>>> Would like more comments.
>>>>>
>>>>
>>>> If there are no major comments at this time, can we proceed with
>>>> accepting and merging this notice in this release. Further review can
>>>> continue once the RFC is available next month.
>>>>
>>>> Thanks & Regards
>>>> Vamsi
>>>>
>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> On 2025/7/15 13:35, Vamsi Krishna Attunuru wrote:
>>>>>>>> Hi Feng,
>>>>>>>>
>>>>>>>> Thanks for depicting the feature use case.
>>>>>>>>
>>>>>>>> From the application’s perspective, inter VM/process
>>>>>>>> communication is
>>>>>>> required to exchange the src & dst buffer details, however the
>>>>>>> specifics of this communication mechanism are outside the scope in
>>>>>>> this context. Regarding the address translations, these buffer
>>>>>>> addresses can be either IOVA as PA or IOVA as VA. The DMA hardware
>>>>>>> must use the appropriate IOMMU stream IDs when initiating the DMA
>>>>>>> transfers. For example, in the use case shown in the diagram,
>>>>>>> dmadev-1 and dmadev-2 would join an access group managed by the
>>>>>>> kernel DMA controller driver. This controller driver will
>>>>>>> configure the access group on the DMA hardware, enabling the
>>>>>>> hardware to select the correct stream IDs for read/write
>>>>>>> operations. New rte_dma APIs could be introduced to join or leave
>>>>>>> the access group or to query the access group details.
>>>>>>> Additionally, a secure token mechanism (similar to
>>>>> vfio-pci token) can be implemented to validate any dmadev attempting
>>>>> to join the access group.
>>>>>>>>
>>>>>>>> Regards.
>>>>>>>>
>>>>>>>> From: fengchengwen <fengchengwen@huawei.com>
>>>>>>>> Sent: Tuesday, July 15, 2025 6:29 AM
>>>>>>>> To: Vamsi Krishna Attunuru <vattunuru@marvell.com>;
>>> dev@dpdk.org;
>>>>>>>> Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>;
>>>>>>>> kevin.laatz@intel.com; bruce.richardson@intel.com;
>>>>>>>> mb@smartsharesystems.com
>>>>>>>> Cc: Jerin Jacob <jerinj@marvell.com>; thomas@monjalon.net
>>>>>>>> Subject: [EXTERNAL] Re: [PATCH v0 1/1] doc: announce inter-device
>>>>>>>> DMA capability support in dmadev
>>>>>>>>
>>>>>>>> Hi Vamsi, From the commit log, I guess this commit mainly want to
>>>>>>>> meet following case: --------------- ---------------- | Container
>>>>>>>> |
>>>>>>>> | VirtMachine | | | | | | dmadev-1 | | dmadev2 | ---------------
>>>>>>>> ---------------- |
>>>>>>> | ------------------------------ ZjQcmQRYFpfptBannerStart
>>>>>>> | Prioritize security for
>>>>>>> external emails:
>>>>>>>> Confirm sender and content safety before clicking links or
>>>>>>>> opening
>>>>>>> attachments
>>>>>>>> Report Suspicious
>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__us-
>>>> 2Dphishala
>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__us-
>>>>>>>>>> 2Dphishala >>>>>>> r
>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__us-
>>>> 2Dphishala
>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__us-
>>>>>>>>>> 2Dphishala >>>>>>> r >>>>> m-
>>>>> 2D&d=DwIDaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=WllrYaumVkxaWjgKto6
>> E
>>> _r
>>>> t
>>>>> DQsh
>>>>>>>>
>>>>> hIhik2jkvzFyRhW8&m=3uFGFVHxC4YLkjWHNg9s9rNDHd_ozbhLepOYCAki
>> Z
>>> K
>>>> x
>>>>> M0sQ0m
>>>>>>>>
>>>>> 43gqgTQl1cK9koZ&s=3_mvLYuMWu7RbHD3mj21CP65O5JY8L8AK8oVFutdT
>>> W
>>>> U
>>>>> &e=
>>>>>>>
>>>>> ewt.proofpoint.com/EWT/v1/CRVmXkqW!tg3ZldV0Yr_wdSwWmT2aDdK
>> Mi
>>> -
>>>>>>>
>>>>> 4rn2z58vFaxwfOeocS1P19w1BeRdyGs5sjnhV2rU_6m8MOWj4KFbuXKkKJI
>> v
>>> c
>>>> q
>>>>>>> wWD2WEwJW_0$ >
>>>>>>>> ZjQcmQRYFpfptBannerEnd
>>>>>>>>
>>>>>>>> Hi Vamsi,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> From the commit log, I guess this commit mainly want to meet
>>>>>>>> following
>>>>>>> case:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --------------- ----------------
>>>>>>>>
>>>>>>>> | Container | | VirtMachine |
>>>>>>>>
>>>>>>>> | | | |
>>>>>>>>
>>>>>>>> | dmadev-1 | | dmadev2 |
>>>>>>>>
>>>>>>>> --------------- ----------------
>>>>>>>>
>>>>>>>> | |
>>>>>>>>
>>>>>>>> ------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> App run in the container could launch DMA transfer from local
>>>>>>>> buffer to the VirtMachine by config
>>>>>>>>
>>>>>>>> dmadev-1/2 (the dmadev-1/2 are passthrough to diffent OS domain).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Could you explain how to use it from application perspective (for
>>>>>>>> example address translation) and
>>>>>>>>
>>>>>>>> application & hardware restrictions?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> BTW: In this case, there are two OS domain communication, and I
>>>>>>>> remember there are also inter-process
>>>>>>>>
>>>>>>>> DMA RFC, so maybe we could design more generic solution if you
>>>>>>>> provide
>>>>>>> more info.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2025/7/10 16:51, Vamsi Krishna wrote:
>>>>>>>>
>>>>>>>>> From: Vamsi Attunuru
>>>>>>>>> <vattunuru@marvell.com<mailto:vattunuru@marvell.com>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>> Modern DMA hardware supports data transfer between multiple
>>>>>>>>
>>>>>>>>> DMA devices, enabling data communication across isolated domains
>>>>>>>>> or
>>>>>>>>
>>>>>>>>> containers. To facilitate this, the ``dmadev`` library requires
>>>>>>>>> changes
>>>>>>>>
>>>>>>>>> to allow devices to register with or unregisters from DMA groups
>>>>>>>>> for
>>>>>>>>
>>>>>>>>> inter-device communication. This feature is planned for
>>>>>>>>> inclusion
>>>>>>>>
>>>>>>>>> in DPDK 25.11.
>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>> Signed-off-by: Vamsi Attunuru
>>>>>>>>> <vattunuru@marvell.com<mailto:vattunuru@marvell.com>>
>>>>>>>>
>>>>>>>>> ---
>>>>>>>>
>>>>>>>>> doc/guides/rel_notes/deprecation.rst | 7 +++++++
>>>>>>>>
>>>>>>>>> 1 file changed, 7 insertions(+)
>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>> diff --git a/doc/guides/rel_notes/deprecation.rst
>>>>>>>>> b/doc/guides/rel_notes/deprecation.rst
>>>>>>>>
>>>>>>>>> index e2d4125308..46836244dd 100644
>>>>>>>>
>>>>>>>>> --- a/doc/guides/rel_notes/deprecation.rst
>>>>>>>>
>>>>>>>>> +++ b/doc/guides/rel_notes/deprecation.rst
>>>>>>>>
>>>>>>>>> @@ -152,3 +152,10 @@ Deprecation Notices
>>>>>>>>
>>>>>>>>> * bus/vmbus: Starting DPDK 25.11, all the vmbus API defined in
>>>>>>>>
>>>>>>>>> ``drivers/bus/vmbus/rte_bus_vmbus.h`` will become internal to
>>>> DPDK.
>>>>>>>>
>>>>>>>>> Those API functions are used internally by DPDK core and
>>>>>>>>> netvsc
>>>> PMD.
>>>>>>>>
>>>>>>>>> +
>>>>>>>>
>>>>>>>>> +* dmadev: a new capability flag ``RTE_DMA_CAPA_INTER_DEV``
>> will
>>>>>>>>> +be added
>>>>>>>>
>>>>>>>>> + to advertise DMA device's inter-device DMA copy capability.
>>>>>>>>> + To enable
>>>>>>>>
>>>>>>>>> + this functionality, a few dmadev APIs will be added to
>>>>>>>>> + configure the DMA
>>>>>>>>
>>>>>>>>> + access groups, facilitating coordinated data communication
>>>>>>>>> + between
>>>>>>> devices.
>>>>>>>>
>>>>>>>>> + A new ``dev_idx`` field will be added to the ``struct
>>>>>>>>> + rte_dma_vchan_conf``
>>>>>>>>
>>>>>>>>> + structure to configure a vchan for data transfers between any
>>>>>>>>> + two DMA
>>>>>>> devices.
>>>>>>>>
>>>>>>>>
>>>>>>
>
^ permalink raw reply [relevance 0%]
* [RFC 1/3] hash: move table of hash compare functions out of header
@ 2025-08-21 20:35 7% ` Stephen Hemminger
2025-08-22 9:05 0% ` Morten Brørup
1 sibling, 1 reply; 15+ results
From: Stephen Hemminger @ 2025-08-21 20:35 UTC (permalink / raw)
To: dev
Cc: Stephen Hemminger, Yipeng Wang, Sameh Gobriel, Bruce Richardson,
Vladimir Medvedkin
Remove the definition of the compare jump table from the
header file so the internal details are not exposed.
Prevents future ABI breakage if new sizes are added.
Make other macros local if possible, header should
only contain exposed API.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/hash/rte_cuckoo_hash.c | 74 ++++++++++++++++++++++++++++++-----
lib/hash/rte_cuckoo_hash.h | 79 +-------------------------------------
2 files changed, 65 insertions(+), 88 deletions(-)
diff --git a/lib/hash/rte_cuckoo_hash.c b/lib/hash/rte_cuckoo_hash.c
index 2c92c51624..619fe0c691 100644
--- a/lib/hash/rte_cuckoo_hash.c
+++ b/lib/hash/rte_cuckoo_hash.c
@@ -25,14 +25,51 @@
#include <rte_tailq.h>
#include "rte_hash.h"
+#include "rte_cuckoo_hash.h"
-/* needs to be before rte_cuckoo_hash.h */
RTE_LOG_REGISTER_DEFAULT(hash_logtype, INFO);
#define RTE_LOGTYPE_HASH hash_logtype
#define HASH_LOG(level, ...) \
RTE_LOG_LINE(level, HASH, "" __VA_ARGS__)
-#include "rte_cuckoo_hash.h"
+/* Macro to enable/disable run-time checking of function parameters */
+#if defined(RTE_LIBRTE_HASH_DEBUG)
+#define RETURN_IF_TRUE(cond, retval) do { \
+ if (cond) \
+ return retval; \
+} while (0)
+#else
+#define RETURN_IF_TRUE(cond, retval)
+#endif
+
+#if defined(RTE_ARCH_X86)
+#include "rte_cmp_x86.h"
+#endif
+
+#if defined(RTE_ARCH_ARM64)
+#include "rte_cmp_arm64.h"
+#endif
+
+/*
+ * All different options to select a key compare function,
+ * based on the key size and custom function.
+ * Not in rte_cuckoo_hash.h to avoid ABI issues.
+ */
+enum cmp_jump_table_case {
+ KEY_CUSTOM = 0,
+#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64)
+ KEY_16_BYTES,
+ KEY_32_BYTES,
+ KEY_48_BYTES,
+ KEY_64_BYTES,
+ KEY_80_BYTES,
+ KEY_96_BYTES,
+ KEY_112_BYTES,
+ KEY_128_BYTES,
+#endif
+ KEY_OTHER_BYTES,
+ NUM_KEY_CMP_CASES,
+};
/* Enum used to select the implementation of the signature comparison function to use
* eg: a system supporting SVE might want to use a NEON or scalar implementation.
@@ -117,6 +154,25 @@ void rte_hash_set_cmp_func(struct rte_hash *h, rte_hash_cmp_eq_t func)
h->rte_hash_custom_cmp_eq = func;
}
+/*
+ * Table storing all different key compare functions
+ * (multi-process supported)
+ */
+static const rte_hash_cmp_eq_t cmp_jump_table[NUM_KEY_CMP_CASES] = {
+ [KEY_CUSTOM] = NULL,
+#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64)
+ [KEY_16_BYTES] = rte_hash_k16_cmp_eq,
+ [KEY_32_BYTES] = rte_hash_k32_cmp_eq,
+ [KEY_48_BYTES] = rte_hash_k48_cmp_eq,
+ [KEY_64_BYTES] = rte_hash_k64_cmp_eq,
+ [KEY_80_BYTES] = rte_hash_k80_cmp_eq,
+ [KEY_96_BYTES] = rte_hash_k96_cmp_eq,
+ [KEY_112_BYTES] = rte_hash_k112_cmp_eq,
+ [KEY_128_BYTES] = rte_hash_k128_cmp_eq,
+#endif
+ [KEY_OTHER_BYTES] = memcmp,
+};
+
static inline int
rte_hash_cmp_eq(const void *key1, const void *key2, const struct rte_hash *h)
{
@@ -390,13 +446,13 @@ rte_hash_create(const struct rte_hash_parameters *params)
goto err_unlock;
}
-/*
- * If x86 architecture is used, select appropriate compare function,
- * which may use x86 intrinsics, otherwise use memcmp
- */
-#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64)
/* Select function to compare keys */
switch (params->key_len) {
+#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64)
+ /*
+ * If x86 architecture is used, select appropriate compare function,
+ * which may use x86 intrinsics, otherwise use memcmp
+ */
case 16:
h->cmp_jump_table_idx = KEY_16_BYTES;
break;
@@ -421,13 +477,11 @@ rte_hash_create(const struct rte_hash_parameters *params)
case 128:
h->cmp_jump_table_idx = KEY_128_BYTES;
break;
+#endif
default:
/* If key is not multiple of 16, use generic memcmp */
h->cmp_jump_table_idx = KEY_OTHER_BYTES;
}
-#else
- h->cmp_jump_table_idx = KEY_OTHER_BYTES;
-#endif
if (use_local_cache) {
local_free_slots = rte_zmalloc_socket(NULL,
diff --git a/lib/hash/rte_cuckoo_hash.h b/lib/hash/rte_cuckoo_hash.h
index 26a992419a..16fe999c4c 100644
--- a/lib/hash/rte_cuckoo_hash.h
+++ b/lib/hash/rte_cuckoo_hash.h
@@ -12,86 +12,9 @@
#define _RTE_CUCKOO_HASH_H_
#include <stdalign.h>
-
-#if defined(RTE_ARCH_X86)
-#include "rte_cmp_x86.h"
-#endif
-
-#if defined(RTE_ARCH_ARM64)
-#include "rte_cmp_arm64.h"
-#endif
-
-/* Macro to enable/disable run-time checking of function parameters */
-#if defined(RTE_LIBRTE_HASH_DEBUG)
-#define RETURN_IF_TRUE(cond, retval) do { \
- if (cond) \
- return retval; \
-} while (0)
-#else
-#define RETURN_IF_TRUE(cond, retval)
-#endif
-
#include <rte_hash_crc.h>
#include <rte_jhash.h>
-#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64)
-/*
- * All different options to select a key compare function,
- * based on the key size and custom function.
- */
-enum cmp_jump_table_case {
- KEY_CUSTOM = 0,
- KEY_16_BYTES,
- KEY_32_BYTES,
- KEY_48_BYTES,
- KEY_64_BYTES,
- KEY_80_BYTES,
- KEY_96_BYTES,
- KEY_112_BYTES,
- KEY_128_BYTES,
- KEY_OTHER_BYTES,
- NUM_KEY_CMP_CASES,
-};
-
-/*
- * Table storing all different key compare functions
- * (multi-process supported)
- */
-const rte_hash_cmp_eq_t cmp_jump_table[NUM_KEY_CMP_CASES] = {
- NULL,
- rte_hash_k16_cmp_eq,
- rte_hash_k32_cmp_eq,
- rte_hash_k48_cmp_eq,
- rte_hash_k64_cmp_eq,
- rte_hash_k80_cmp_eq,
- rte_hash_k96_cmp_eq,
- rte_hash_k112_cmp_eq,
- rte_hash_k128_cmp_eq,
- memcmp
-};
-#else
-/*
- * All different options to select a key compare function,
- * based on the key size and custom function.
- */
-enum cmp_jump_table_case {
- KEY_CUSTOM = 0,
- KEY_OTHER_BYTES,
- NUM_KEY_CMP_CASES,
-};
-
-/*
- * Table storing all different key compare functions
- * (multi-process supported)
- */
-const rte_hash_cmp_eq_t cmp_jump_table[NUM_KEY_CMP_CASES] = {
- NULL,
- memcmp
-};
-
-#endif
-
-
/**
* Number of items per bucket.
* 8 is a tradeoff between performance and memory consumption.
@@ -189,7 +112,7 @@ struct __rte_cache_aligned rte_hash {
uint32_t hash_func_init_val; /**< Init value used by hash_func. */
rte_hash_cmp_eq_t rte_hash_custom_cmp_eq;
/**< Custom function used to compare keys. */
- enum cmp_jump_table_case cmp_jump_table_idx;
+ unsigned int cmp_jump_table_idx;
/**< Indicates which compare function to use. */
unsigned int sig_cmp_fn;
/**< Indicates which signature compare function to use. */
--
2.47.2
^ permalink raw reply [relevance 7%]
* RE: [RFC 1/3] hash: move table of hash compare functions out of header
2025-08-21 20:35 7% ` [RFC 1/3] hash: move table of hash compare functions out of header Stephen Hemminger
@ 2025-08-22 9:05 0% ` Morten Brørup
0 siblings, 0 replies; 15+ results
From: Morten Brørup @ 2025-08-22 9:05 UTC (permalink / raw)
To: Stephen Hemminger, dev
Cc: Yipeng Wang, Sameh Gobriel, Bruce Richardson, Vladimir Medvedkin
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Thursday, 21 August 2025 22.35
>
> Remove the definition of the compare jump table from the
> header file so the internal details are not exposed.
> Prevents future ABI breakage if new sizes are added.
>
> Make other macros local if possible, header should
> only contain exposed API.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
[...]
> +/*
> + * All different options to select a key compare function,
> + * based on the key size and custom function.
> + * Not in rte_cuckoo_hash.h to avoid ABI issues.
> + */
> +enum cmp_jump_table_case {
> + KEY_CUSTOM = 0,
> +#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64)
> + KEY_16_BYTES,
> + KEY_32_BYTES,
> + KEY_48_BYTES,
> + KEY_64_BYTES,
> + KEY_80_BYTES,
> + KEY_96_BYTES,
> + KEY_112_BYTES,
> + KEY_128_BYTES,
> +#endif
> + KEY_OTHER_BYTES,
> + NUM_KEY_CMP_CASES,
> +};
>
> /* Enum used to select the implementation of the signature comparison
> function to use
> * eg: a system supporting SVE might want to use a NEON or scalar
> implementation.
> @@ -117,6 +154,25 @@ void rte_hash_set_cmp_func(struct rte_hash *h,
> rte_hash_cmp_eq_t func)
> h->rte_hash_custom_cmp_eq = func;
> }
>
> +/*
> + * Table storing all different key compare functions
> + * (multi-process supported)
> + */
> +static const rte_hash_cmp_eq_t cmp_jump_table[NUM_KEY_CMP_CASES] = {
> + [KEY_CUSTOM] = NULL,
> +#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64)
> + [KEY_16_BYTES] = rte_hash_k16_cmp_eq,
> + [KEY_32_BYTES] = rte_hash_k32_cmp_eq,
> + [KEY_48_BYTES] = rte_hash_k48_cmp_eq,
> + [KEY_64_BYTES] = rte_hash_k64_cmp_eq,
> + [KEY_80_BYTES] = rte_hash_k80_cmp_eq,
> + [KEY_96_BYTES] = rte_hash_k96_cmp_eq,
> + [KEY_112_BYTES] = rte_hash_k112_cmp_eq,
> + [KEY_128_BYTES] = rte_hash_k128_cmp_eq,
> +#endif
> + [KEY_OTHER_BYTES] = memcmp,
> +};
Nice trick explicitly indexing these here; it reduces the risk of not matching the cmp_jump_table_case.
Consider adding static_assert() that RTE_DIM(cmp_jump_table) == NUM_KEY_CMP_CASES.
With or without suggested static_assert()...
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Good cleanup!
^ permalink raw reply [relevance 0%]
* [dpdk-dev v9 1/3] cryptodev: add ec points to sm2 op
@ 2025-08-22 11:13 4% ` Kai Ji
0 siblings, 0 replies; 15+ results
From: Kai Ji @ 2025-08-22 11:13 UTC (permalink / raw)
To: dev; +Cc: Kai Ji, Arkadiusz Kusztal, Akhil Goyal, Fan Zhang
In the case when PMD cannot support the full process of the SM2,
but elliptic curve computation only, additional fields
are needed to handle such a case.
Points C1, kP therefore were added to the SM2 crypto operation struct.
Signed-off-by: Arkadiusz Kusztal <arkadiuszx.kusztal@intel.com>
Signed-off-by: Kai Ji <kai.ji@intel.com>
---
doc/guides/rel_notes/release_25_11.rst | 2 +
lib/cryptodev/rte_crypto_asym.h | 56 +++++++++++++++++++-------
2 files changed, 44 insertions(+), 14 deletions(-)
diff --git a/doc/guides/rel_notes/release_25_11.rst b/doc/guides/rel_notes/release_25_11.rst
index ccad6d89ff..b15d2e0e8f 100644
--- a/doc/guides/rel_notes/release_25_11.rst
+++ b/doc/guides/rel_notes/release_25_11.rst
@@ -100,6 +100,8 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* cryptodev: The ``rte_crypto_sm2_op_param`` struct member to hold ciphertext
+ is changed to union data type. This change is to support partial SM2 calculation.
Known Issues
------------
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 9787b710e7..039dcb85a7 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -654,6 +654,8 @@ enum rte_crypto_sm2_op_capa {
/**< Random number generator supported in SM2 ops. */
RTE_CRYPTO_SM2_PH,
/**< Prehash message before crypto op. */
+ RTE_CRYPTO_SM2_PARTIAL,
+ /**< Calculate elliptic curve points only. */
};
/**
@@ -681,20 +683,46 @@ struct rte_crypto_sm2_op_param {
* will be overwritten by the PMD with the decrypted length.
*/
- rte_crypto_param cipher;
- /**<
- * Pointer to input data
- * - to be decrypted for SM2 private decrypt.
- *
- * Pointer to output data
- * - for SM2 public encrypt.
- * In this case the underlying array should have been allocated
- * with enough memory to hold ciphertext output (at least X bytes
- * for prime field curve of N bytes and for message M bytes,
- * where X = (C1 || C2 || C3) and computed based on SM2 RFC as
- * C1 (1 + N + N), C2 = M, C3 = N. The cipher.length field will
- * be overwritten by the PMD with the encrypted length.
- */
+ union {
+ rte_crypto_param cipher;
+ /**<
+ * Pointer to input data
+ * - to be decrypted for SM2 private decrypt.
+ *
+ * Pointer to output data
+ * - for SM2 public encrypt.
+ * In this case the underlying array should have been allocated
+ * with enough memory to hold ciphertext output (at least X bytes
+ * for prime field curve of N bytes and for message M bytes,
+ * where X = (C1 || C2 || C3) and computed based on SM2 RFC as
+ * C1 (1 + N + N), C2 = M, C3 = N. The cipher.length field will
+ * be overwritten by the PMD with the encrypted length.
+ */
+ struct {
+ struct rte_crypto_ec_point c1;
+ /**<
+ * This field is used only when PMD does not support the full
+ * process of the SM2 encryption/decryption, but the elliptic
+ * curve part only.
+ *
+ * In the case of encryption, it is an output - point C1 = (x1,y1).
+ * In the case of decryption, if is an input - point C1 = (x1,y1).
+ *
+ * Must be used along with the RTE_CRYPTO_SM2_PARTIAL flag.
+ */
+ struct rte_crypto_ec_point kp;
+ /**<
+ * This field is used only when PMD does not support the full
+ * process of the SM2 encryption/decryption, but the elliptic
+ * curve part only.
+ *
+ * It is an output in the encryption case, it is a point
+ * [k]P = (x2,y2).
+ *
+ * Must be used along with the RTE_CRYPTO_SM2_PARTIAL flag.
+ */
+ };
+ };
rte_crypto_uint id;
/**< The SM2 id used by signer and verifier. */
--
2.43.0
^ permalink raw reply [relevance 4%]
* [PATCH v2 1/4] hash: move table of hash compare functions out of header
@ 2025-08-22 18:19 7% ` Stephen Hemminger
0 siblings, 0 replies; 15+ results
From: Stephen Hemminger @ 2025-08-22 18:19 UTC (permalink / raw)
To: dev
Cc: Stephen Hemminger, Morten Brørup, Yipeng Wang,
Sameh Gobriel, Bruce Richardson, Vladimir Medvedkin
Remove the definition of the compare jump table from the
header file so the internal details are not exposed.
Prevents future ABI breakage if new sizes are added.
Make other macros local if possible, header should
only contain exposed API.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
lib/hash/rte_cuckoo_hash.c | 74 ++++++++++++++++++++++++++++++-----
lib/hash/rte_cuckoo_hash.h | 79 +-------------------------------------
2 files changed, 65 insertions(+), 88 deletions(-)
diff --git a/lib/hash/rte_cuckoo_hash.c b/lib/hash/rte_cuckoo_hash.c
index 2c92c51624..619fe0c691 100644
--- a/lib/hash/rte_cuckoo_hash.c
+++ b/lib/hash/rte_cuckoo_hash.c
@@ -25,14 +25,51 @@
#include <rte_tailq.h>
#include "rte_hash.h"
+#include "rte_cuckoo_hash.h"
-/* needs to be before rte_cuckoo_hash.h */
RTE_LOG_REGISTER_DEFAULT(hash_logtype, INFO);
#define RTE_LOGTYPE_HASH hash_logtype
#define HASH_LOG(level, ...) \
RTE_LOG_LINE(level, HASH, "" __VA_ARGS__)
-#include "rte_cuckoo_hash.h"
+/* Macro to enable/disable run-time checking of function parameters */
+#if defined(RTE_LIBRTE_HASH_DEBUG)
+#define RETURN_IF_TRUE(cond, retval) do { \
+ if (cond) \
+ return retval; \
+} while (0)
+#else
+#define RETURN_IF_TRUE(cond, retval)
+#endif
+
+#if defined(RTE_ARCH_X86)
+#include "rte_cmp_x86.h"
+#endif
+
+#if defined(RTE_ARCH_ARM64)
+#include "rte_cmp_arm64.h"
+#endif
+
+/*
+ * All different options to select a key compare function,
+ * based on the key size and custom function.
+ * Not in rte_cuckoo_hash.h to avoid ABI issues.
+ */
+enum cmp_jump_table_case {
+ KEY_CUSTOM = 0,
+#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64)
+ KEY_16_BYTES,
+ KEY_32_BYTES,
+ KEY_48_BYTES,
+ KEY_64_BYTES,
+ KEY_80_BYTES,
+ KEY_96_BYTES,
+ KEY_112_BYTES,
+ KEY_128_BYTES,
+#endif
+ KEY_OTHER_BYTES,
+ NUM_KEY_CMP_CASES,
+};
/* Enum used to select the implementation of the signature comparison function to use
* eg: a system supporting SVE might want to use a NEON or scalar implementation.
@@ -117,6 +154,25 @@ void rte_hash_set_cmp_func(struct rte_hash *h, rte_hash_cmp_eq_t func)
h->rte_hash_custom_cmp_eq = func;
}
+/*
+ * Table storing all different key compare functions
+ * (multi-process supported)
+ */
+static const rte_hash_cmp_eq_t cmp_jump_table[NUM_KEY_CMP_CASES] = {
+ [KEY_CUSTOM] = NULL,
+#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64)
+ [KEY_16_BYTES] = rte_hash_k16_cmp_eq,
+ [KEY_32_BYTES] = rte_hash_k32_cmp_eq,
+ [KEY_48_BYTES] = rte_hash_k48_cmp_eq,
+ [KEY_64_BYTES] = rte_hash_k64_cmp_eq,
+ [KEY_80_BYTES] = rte_hash_k80_cmp_eq,
+ [KEY_96_BYTES] = rte_hash_k96_cmp_eq,
+ [KEY_112_BYTES] = rte_hash_k112_cmp_eq,
+ [KEY_128_BYTES] = rte_hash_k128_cmp_eq,
+#endif
+ [KEY_OTHER_BYTES] = memcmp,
+};
+
static inline int
rte_hash_cmp_eq(const void *key1, const void *key2, const struct rte_hash *h)
{
@@ -390,13 +446,13 @@ rte_hash_create(const struct rte_hash_parameters *params)
goto err_unlock;
}
-/*
- * If x86 architecture is used, select appropriate compare function,
- * which may use x86 intrinsics, otherwise use memcmp
- */
-#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64)
/* Select function to compare keys */
switch (params->key_len) {
+#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64)
+ /*
+ * If x86 architecture is used, select appropriate compare function,
+ * which may use x86 intrinsics, otherwise use memcmp
+ */
case 16:
h->cmp_jump_table_idx = KEY_16_BYTES;
break;
@@ -421,13 +477,11 @@ rte_hash_create(const struct rte_hash_parameters *params)
case 128:
h->cmp_jump_table_idx = KEY_128_BYTES;
break;
+#endif
default:
/* If key is not multiple of 16, use generic memcmp */
h->cmp_jump_table_idx = KEY_OTHER_BYTES;
}
-#else
- h->cmp_jump_table_idx = KEY_OTHER_BYTES;
-#endif
if (use_local_cache) {
local_free_slots = rte_zmalloc_socket(NULL,
diff --git a/lib/hash/rte_cuckoo_hash.h b/lib/hash/rte_cuckoo_hash.h
index 26a992419a..16fe999c4c 100644
--- a/lib/hash/rte_cuckoo_hash.h
+++ b/lib/hash/rte_cuckoo_hash.h
@@ -12,86 +12,9 @@
#define _RTE_CUCKOO_HASH_H_
#include <stdalign.h>
-
-#if defined(RTE_ARCH_X86)
-#include "rte_cmp_x86.h"
-#endif
-
-#if defined(RTE_ARCH_ARM64)
-#include "rte_cmp_arm64.h"
-#endif
-
-/* Macro to enable/disable run-time checking of function parameters */
-#if defined(RTE_LIBRTE_HASH_DEBUG)
-#define RETURN_IF_TRUE(cond, retval) do { \
- if (cond) \
- return retval; \
-} while (0)
-#else
-#define RETURN_IF_TRUE(cond, retval)
-#endif
-
#include <rte_hash_crc.h>
#include <rte_jhash.h>
-#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64)
-/*
- * All different options to select a key compare function,
- * based on the key size and custom function.
- */
-enum cmp_jump_table_case {
- KEY_CUSTOM = 0,
- KEY_16_BYTES,
- KEY_32_BYTES,
- KEY_48_BYTES,
- KEY_64_BYTES,
- KEY_80_BYTES,
- KEY_96_BYTES,
- KEY_112_BYTES,
- KEY_128_BYTES,
- KEY_OTHER_BYTES,
- NUM_KEY_CMP_CASES,
-};
-
-/*
- * Table storing all different key compare functions
- * (multi-process supported)
- */
-const rte_hash_cmp_eq_t cmp_jump_table[NUM_KEY_CMP_CASES] = {
- NULL,
- rte_hash_k16_cmp_eq,
- rte_hash_k32_cmp_eq,
- rte_hash_k48_cmp_eq,
- rte_hash_k64_cmp_eq,
- rte_hash_k80_cmp_eq,
- rte_hash_k96_cmp_eq,
- rte_hash_k112_cmp_eq,
- rte_hash_k128_cmp_eq,
- memcmp
-};
-#else
-/*
- * All different options to select a key compare function,
- * based on the key size and custom function.
- */
-enum cmp_jump_table_case {
- KEY_CUSTOM = 0,
- KEY_OTHER_BYTES,
- NUM_KEY_CMP_CASES,
-};
-
-/*
- * Table storing all different key compare functions
- * (multi-process supported)
- */
-const rte_hash_cmp_eq_t cmp_jump_table[NUM_KEY_CMP_CASES] = {
- NULL,
- memcmp
-};
-
-#endif
-
-
/**
* Number of items per bucket.
* 8 is a tradeoff between performance and memory consumption.
@@ -189,7 +112,7 @@ struct __rte_cache_aligned rte_hash {
uint32_t hash_func_init_val; /**< Init value used by hash_func. */
rte_hash_cmp_eq_t rte_hash_custom_cmp_eq;
/**< Custom function used to compare keys. */
- enum cmp_jump_table_case cmp_jump_table_idx;
+ unsigned int cmp_jump_table_idx;
/**< Indicates which compare function to use. */
unsigned int sig_cmp_fn;
/**< Indicates which signature compare function to use. */
--
2.47.2
^ permalink raw reply [relevance 7%]
Results 14001-14015 of 14015 prev (older) | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2024-05-29 23:33 [PATCH v10 00/20] Remove use of noninclusive term sanity Stephen Hemminger
2025-04-02 23:23 ` [PATCH v12 00/10] replace use of term sanity check Stephen Hemminger
2025-04-02 23:23 ` [PATCH v12 01/10] mbuf: replace " Stephen Hemminger
2025-08-11 9:55 0% ` Morten Brørup
2025-08-11 15:20 0% ` Stephen Hemminger
2024-11-04 9:36 [PATCH v8 1/3] cryptodev: add ec points to sm2 op Arkadiusz Kusztal
2025-08-22 11:13 4% ` [dpdk-dev v9 " Kai Ji
2025-04-16 11:05 [PATCH] doc: announce DMA configuration structure changes pbhagavatula
2025-06-24 6:22 ` [EXTERNAL] " Amit Prakash Shukla
2025-07-21 17:49 ` Thomas Monjalon
2025-07-25 6:04 0% ` Pavan Nikhilesh Bhagavatula
2025-07-26 0:55 0% ` fengchengwen
2025-07-28 5:11 4% ` Pavan Nikhilesh Bhagavatula
2025-08-12 10:59 0% ` Thomas Monjalon
2025-06-05 11:31 [PATCH] ethdev: add support to provide link type skori
2025-06-06 9:28 ` [PATCH v2 1/1] " skori
2025-06-06 9:54 ` Morten Brørup
2025-06-06 15:23 ` Stephen Hemminger
2025-06-10 5:02 ` [EXTERNAL] " Sunil Kumar Kori
2025-06-10 6:45 ` Morten Brørup
2025-08-13 7:42 4% ` Sunil Kumar Kori
2025-06-19 7:10 [PATCH 00/10] Run with UBSan in GHA David Marchand
2025-07-23 13:31 ` [PATCH v5 00/22] " David Marchand
2025-07-23 13:31 8% ` [PATCH v5 12/22] ipc: fix mp message alignment for malloc David Marchand
2025-07-10 8:51 [PATCH v0 1/1] doc: announce inter-device DMA capability support in dmadev Vamsi Krishna
2025-07-15 0:59 ` fengchengwen
2025-07-15 5:35 ` [EXTERNAL] " Vamsi Krishna Attunuru
2025-07-16 4:14 ` fengchengwen
2025-07-16 10:59 ` Vamsi Krishna Attunuru
2025-07-17 1:40 ` fengchengwen
2025-07-18 2:29 ` Vamsi Krishna Attunuru
2025-07-28 5:35 ` Vamsi Krishna Attunuru
2025-07-30 4:36 ` Vamsi Krishna Attunuru
2025-08-13 16:46 3% ` Vamsi Krishna Attunuru
2025-08-14 0:44 0% ` fengchengwen
2025-07-22 13:24 [PATCH 1/2] version: 25.11.0-rc0 David Marchand
2025-07-22 13:24 ` [PATCH 2/2] net: remove v25 ABI compatibility David Marchand
2025-07-23 12:14 ` Bruce Richardson
2025-07-24 10:10 4% ` Finn, Emma
2025-08-21 20:35 [RFC 0/3] hash: optimize compare logic Stephen Hemminger
2025-08-21 20:35 7% ` [RFC 1/3] hash: move table of hash compare functions out of header Stephen Hemminger
2025-08-22 9:05 0% ` Morten Brørup
2025-08-22 18:19 ` [PATCH v2 0/4] Cuckoo hash cleanup and optimizations Stephen Hemminger
2025-08-22 18:19 7% ` [PATCH v2 1/4] hash: move table of hash compare functions out of header Stephen Hemminger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).