public inbox for dev@dpdk.org
 help / color / mirror / Atom feed
* FW: [PATCH] mbuf: fix packet copy
@ 2026-01-15 10:53 Morten Brørup
  2026-01-15 13:27 ` Morten Brørup
  2026-01-16  5:55 ` Stephen Hemminger
  0 siblings, 2 replies; 4+ messages in thread
From: Morten Brørup @ 2026-01-15 10:53 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: dev, stable

Stephen,

As the author of rte_pktmbuf_copy(), can you please review this patch?

You might find my answers to Konstantin's review informative:
https://patchwork.dpdk.org/project/dpdk/patch/20251119120403.907511-1-mb@smartsharesystems.com/#181914


Venlig hilsen / Kind regards,
-Morten Brørup


From: Morten Brørup [mailto:mb@smartsharesystems.com] 
Sent: Wednesday, 19 November 2025 13.04

Requests for copying the at the end of a packet incorrectly returned NULL,
as if copying past the end of a packet.

When allocating copies from a mempool using pinned external buffers, the
external flag was not preserved in these mbufs.

Fixes: c3a90c381daa ("mbuf: add a copy routine")

Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/mbuf/rte_mbuf.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/mbuf/rte_mbuf.c b/lib/mbuf/rte_mbuf.c
index 0d931c7a15..e639aff03e 100644
--- a/lib/mbuf/rte_mbuf.c
+++ b/lib/mbuf/rte_mbuf.c
@@ -675,7 +675,7 @@ rte_pktmbuf_copy(const struct rte_mbuf *m, struct rte_mempool *mp,
 	__rte_mbuf_sanity_check(m, 1);
 
 	/* check for request to copy at offset past end of mbuf */
-	if (unlikely(off >= m->pkt_len))
+	if (unlikely(off > m->pkt_len))
 		return NULL;
 
 	mc = rte_pktmbuf_alloc(mp);
@@ -688,8 +688,8 @@ rte_pktmbuf_copy(const struct rte_mbuf *m, struct rte_mempool *mp,
 
 	__rte_pktmbuf_copy_hdr(mc, m);
 
-	/* 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, and preserve flags of newly allocated mbuf */
+	mc->ol_flags |= m->ol_flags & ~(RTE_MBUF_F_INDIRECT|RTE_MBUF_F_EXTERNAL);
 
 	prev = &mc->next;
 	m_last = mc;
-- 
2.43.0


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

* RE: [PATCH] mbuf: fix packet copy
  2026-01-15 10:53 FW: [PATCH] mbuf: fix packet copy Morten Brørup
@ 2026-01-15 13:27 ` Morten Brørup
  2026-01-16  5:55 ` Stephen Hemminger
  1 sibling, 0 replies; 4+ messages in thread
From: Morten Brørup @ 2026-01-15 13:27 UTC (permalink / raw)
  To: dev; +Cc: stable, Stephen Hemminger

Forwarding an email is apparently a bad idea; patchwork picked it up as a new patch.

Venlig hilsen / Kind regards,
-Morten Brørup


> -----Original Message-----
> From: Morten Brørup [mailto:mb@smartsharesystems.com]
> Sent: Thursday, 15 January 2026 11.53
> To: Stephen Hemminger
> Cc: dev@dpdk.org; stable@dpdk.org
> Subject: FW: [PATCH] mbuf: fix packet copy
> 
> Stephen,
> 
> As the author of rte_pktmbuf_copy(), can you please review this patch?
> 
> You might find my answers to Konstantin's review informative:
> https://patchwork.dpdk.org/project/dpdk/patch/20251119120403.907511-1-
> mb@smartsharesystems.com/#181914
> 
> 
> Venlig hilsen / Kind regards,
> -Morten Brørup
> 
> 
> From: Morten Brørup [mailto:mb@smartsharesystems.com]
> Sent: Wednesday, 19 November 2025 13.04
> 
> Requests for copying the at the end of a packet incorrectly returned
> NULL,
> as if copying past the end of a packet.
> 
> When allocating copies from a mempool using pinned external buffers,
> the
> external flag was not preserved in these mbufs.
> 
> Fixes: c3a90c381daa ("mbuf: add a copy routine")
> 
> Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> ---
>  lib/mbuf/rte_mbuf.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/mbuf/rte_mbuf.c b/lib/mbuf/rte_mbuf.c
> index 0d931c7a15..e639aff03e 100644
> --- a/lib/mbuf/rte_mbuf.c
> +++ b/lib/mbuf/rte_mbuf.c
> @@ -675,7 +675,7 @@ rte_pktmbuf_copy(const struct rte_mbuf *m, struct
> rte_mempool *mp,
>  	__rte_mbuf_sanity_check(m, 1);
> 
>  	/* check for request to copy at offset past end of mbuf */
> -	if (unlikely(off >= m->pkt_len))
> +	if (unlikely(off > m->pkt_len))
>  		return NULL;
> 
>  	mc = rte_pktmbuf_alloc(mp);
> @@ -688,8 +688,8 @@ rte_pktmbuf_copy(const struct rte_mbuf *m, struct
> rte_mempool *mp,
> 
>  	__rte_pktmbuf_copy_hdr(mc, m);
> 
> -	/* 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, and preserve flags of
> newly allocated mbuf */
> +	mc->ol_flags |= m->ol_flags &
> ~(RTE_MBUF_F_INDIRECT|RTE_MBUF_F_EXTERNAL);
> 
>  	prev = &mc->next;
>  	m_last = mc;
> --
> 2.43.0


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

* Re: [PATCH] mbuf: fix packet copy
  2026-01-15 10:53 FW: [PATCH] mbuf: fix packet copy Morten Brørup
  2026-01-15 13:27 ` Morten Brørup
@ 2026-01-16  5:55 ` Stephen Hemminger
  2026-01-16  6:12   ` Morten Brørup
  1 sibling, 1 reply; 4+ messages in thread
From: Stephen Hemminger @ 2026-01-16  5:55 UTC (permalink / raw)
  To: Morten Brørup; +Cc: dev, stable

On Thu, 15 Jan 2026 11:53:19 +0100
Morten Brørup <mb@smartsharesystems.com> wrote:

> Stephen,
> 
> As the author of rte_pktmbuf_copy(), can you please review this patch?
> 
> You might find my answers to Konstantin's review informative:
> https://patchwork.dpdk.org/project/dpdk/patch/20251119120403.907511-1-mb@smartsharesystems.com/#181914
> 
> 
> Venlig hilsen / Kind regards,
> -Morten Brørup
> 
> 
> From: Morten Brørup [mailto:mb@smartsharesystems.com] 
> Sent: Wednesday, 19 November 2025 13.04
> 
> Requests for copying the at the end of a packet incorrectly returned NULL,
> as if copying past the end of a packet.
> 
> When allocating copies from a mempool using pinned external buffers, the
> external flag was not preserved in these mbufs.
> 
> Fixes: c3a90c381daa ("mbuf: add a copy routine")
> 
> Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> ---
>  lib/mbuf/rte_mbuf.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/mbuf/rte_mbuf.c b/lib/mbuf/rte_mbuf.c
> index 0d931c7a15..e639aff03e 100644
> --- a/lib/mbuf/rte_mbuf.c
> +++ b/lib/mbuf/rte_mbuf.c
> @@ -675,7 +675,7 @@ rte_pktmbuf_copy(const struct rte_mbuf *m, struct rte_mempool *mp,
>  	__rte_mbuf_sanity_check(m, 1);
>  
>  	/* check for request to copy at offset past end of mbuf */
> -	if (unlikely(off >= m->pkt_len))
> +	if (unlikely(off > m->pkt_len))
>  		return NULL;

It makes more sense to return NULL (as error) rather than creating a 0
length mbuf in this corner case.

>  	mc = rte_pktmbuf_alloc(mp);
> @@ -688,8 +688,8 @@ rte_pktmbuf_copy(const struct rte_mbuf *m, struct rte_mempool *mp,
>  
>  	__rte_pktmbuf_copy_hdr(mc, m);
>  
> -	/* 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, and preserve flags of newly allocated mbuf */
> +	mc->ol_flags |= m->ol_flags & ~(RTE_MBUF_F_INDIRECT|RTE_MBUF_F_EXTERNAL);

Should have space in expression.
At that point it is a new mbuf (the copy) so offload flags should be clear, not sure
what the issue is here.
But hadn't expected usage of this function with an external mbuf pool.


>  
>  	prev = &mc->next;
>  	m_last = mc;


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

* RE: [PATCH] mbuf: fix packet copy
  2026-01-16  5:55 ` Stephen Hemminger
@ 2026-01-16  6:12   ` Morten Brørup
  0 siblings, 0 replies; 4+ messages in thread
From: Morten Brørup @ 2026-01-16  6:12 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: dev, stable

> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Friday, 16 January 2026 06.55
> 
> On Thu, 15 Jan 2026 11:53:19 +0100
> Morten Brørup <mb@smartsharesystems.com> wrote:
> 
> > Stephen,
> >
> > As the author of rte_pktmbuf_copy(), can you please review this
> patch?
> >
> > You might find my answers to Konstantin's review informative:
> > https://patchwork.dpdk.org/project/dpdk/patch/20251119120403.907511-
> 1-mb@smartsharesystems.com/#181914
> >
> >
> > Venlig hilsen / Kind regards,
> > -Morten Brørup
> >
> >
> > From: Morten Brørup [mailto:mb@smartsharesystems.com]
> > Sent: Wednesday, 19 November 2025 13.04
> >
> > Requests for copying the at the end of a packet incorrectly returned
> NULL,
> > as if copying past the end of a packet.
> >
> > When allocating copies from a mempool using pinned external buffers,
> the
> > external flag was not preserved in these mbufs.
> >
> > Fixes: c3a90c381daa ("mbuf: add a copy routine")
> >
> > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> > ---
> >  lib/mbuf/rte_mbuf.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/lib/mbuf/rte_mbuf.c b/lib/mbuf/rte_mbuf.c
> > index 0d931c7a15..e639aff03e 100644
> > --- a/lib/mbuf/rte_mbuf.c
> > +++ b/lib/mbuf/rte_mbuf.c
> > @@ -675,7 +675,7 @@ rte_pktmbuf_copy(const struct rte_mbuf *m, struct
> rte_mempool *mp,
> >  	__rte_mbuf_sanity_check(m, 1);
> >
> >  	/* check for request to copy at offset past end of mbuf */
> > -	if (unlikely(off >= m->pkt_len))
> > +	if (unlikely(off > m->pkt_len))
> >  		return NULL;
> 
> It makes more sense to return NULL (as error) rather than creating a 0
> length mbuf in this corner case.

As replied to Kontantin, 0 length buffers are perfectly valid, so a library should not optimize them away, on an assumption that they are useless.
E.g. consider TCP, which carries many empty packets, adding feedback information (ACK, SACK) to the TCP header. I know it's a very theoretical example stripping all headers and then adding headers again; but I can creatively imagine something like that.
If a normal application don't want to deal with 0 length buffers, it can optimize them away.
But if an exotic application does want to deal with 0 length buffers, it would be a bug if the library optimized them away.

> 
> >  	mc = rte_pktmbuf_alloc(mp);
> > @@ -688,8 +688,8 @@ rte_pktmbuf_copy(const struct rte_mbuf *m, struct
> rte_mempool *mp,
> >
> >  	__rte_pktmbuf_copy_hdr(mc, m);
> >
> > -	/* 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, and preserve flags of
> newly allocated mbuf */
> > +	mc->ol_flags |= m->ol_flags &
> ~(RTE_MBUF_F_INDIRECT|RTE_MBUF_F_EXTERNAL);
> 
> Should have space in expression.

Yes. Copy-paste bug. :-)

> At that point it is a new mbuf (the copy) so offload flags should be
> clear, not sure
> what the issue is here.
> But hadn't expected usage of this function with an external mbuf pool.

I consider pinned external buffers exotic too, but we need to support them throughout DPDK.
That's the downside of exotic features in core libraries.

> 
> 
> >
> >  	prev = &mc->next;
> >  	m_last = mc;


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

end of thread, other threads:[~2026-01-16  6:12 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-01-15 10:53 FW: [PATCH] mbuf: fix packet copy Morten Brørup
2026-01-15 13:27 ` Morten Brørup
2026-01-16  5:55 ` Stephen Hemminger
2026-01-16  6:12   ` Morten Brørup

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox