DPDK patches and discussions
 help / color / mirror / Atom feed
* bugs in rte_pktmbuf_copy
@ 2025-11-17 11:51 Morten Brørup
  2025-11-17 23:43 ` Stephen Hemminger
  0 siblings, 1 reply; 2+ messages in thread
From: Morten Brørup @ 2025-11-17 11:51 UTC (permalink / raw)
  To: stephen, dev

While working on a rte_pktmbuf_copy_bulk() function, I noticed a couple of bugs in rte_pktmbuf_copy():

1. If the copy is allocated from a mempool using pinned external buffers, the copy's RTE_MBUF_F_EXTERNAL flag is lost.
This is simple to fix:

-	/* copied mbuf is not indirect or external */
-	mc->ol_flags = m->ol_flags & ~(RTE_MBUF_F_INDIRECT|RTE_MBUF_F_EXTERNAL);
+	/* copy flags except indirect and external */
+	mc->ol_flags |= m->ol_flags & ~(RTE_MBUF_F_INDIRECT|RTE_MBUF_F_EXTERNAL);

2. If the packet is copied with non-zero offset, much of the metadata do not apply to the copy, e.g. many of the offload flags and the packet_type field.
Maybe metadata should be reset when copying with a non-zero offset?
Or maybe rte_pktmbuf_copy() should be considered "payload copy", so the copy should have all metadata reset?


Venlig hilsen / Kind regards,
-Morten Brørup


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: bugs in rte_pktmbuf_copy
  2025-11-17 11:51 bugs in rte_pktmbuf_copy Morten Brørup
@ 2025-11-17 23:43 ` Stephen Hemminger
  0 siblings, 0 replies; 2+ messages in thread
From: Stephen Hemminger @ 2025-11-17 23:43 UTC (permalink / raw)
  To: Morten Brørup; +Cc: dev

On Mon, 17 Nov 2025 12:51:51 +0100
Morten Brørup <mb@smartsharesystems.com> wrote:

> While working on a rte_pktmbuf_copy_bulk() function, I noticed a couple of bugs in rte_pktmbuf_copy():
> 
> 1. If the copy is allocated from a mempool using pinned external buffers, the copy's RTE_MBUF_F_EXTERNAL flag is lost.
> This is simple to fix:
> 
> -	/* copied mbuf is not indirect or external */
> -	mc->ol_flags = m->ol_flags & ~(RTE_MBUF_F_INDIRECT|RTE_MBUF_F_EXTERNAL);
> +	/* copy flags except indirect and external */
> +	mc->ol_flags |= m->ol_flags & ~(RTE_MBUF_F_INDIRECT|RTE_MBUF_F_EXTERNAL);

Good catch, external flag needs to be preserved. 


> 2. If the packet is copied with non-zero offset, much of the metadata do not apply to the copy, e.g. many of the offload flags and the packet_type field.
> Maybe metadata should be reset when copying with a non-zero offset?
> Or maybe rte_pktmbuf_copy() should be considered "payload copy", so the copy should have all metadata reset?

The use case for using offset, is for removing tunnel headers. I expect that the code doing so
would know what manipulation of offloads was required. 


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2025-11-17 23:43 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-11-17 11:51 bugs in rte_pktmbuf_copy Morten Brørup
2025-11-17 23:43 ` 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).