All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: <dev@dpdk.org>, <stable@dpdk.org>
Subject: Re: [PATCH] mbuf: fix packet copy
Date: Thu, 15 Jan 2026 21:55:16 -0800	[thread overview]
Message-ID: <20260115215516.68a1c942@phoenix.local> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F65664@smartserver.smartshare.dk>

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;


  parent reply	other threads:[~2026-01-16  5:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2026-01-16  6:12   ` Morten Brørup
  -- strict thread matches above, loose matches on Subject: below --
2025-11-19 12:04 Morten Brørup
2025-11-24 13:35 ` Morten Brørup
2025-11-28 10:50 ` Morten Brørup
2025-12-18 16:12 ` Morten Brørup
2026-01-03 17:46 ` Morten Brørup
2026-01-11 15:19   ` Konstantin Ananyev
2026-01-11 17:43     ` Morten Brørup
2026-01-12 10:56       ` Konstantin Ananyev
2026-01-12 10:58   ` Konstantin Ananyev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260115215516.68a1c942@phoenix.local \
    --to=stephen@networkplumber.org \
    --cc=dev@dpdk.org \
    --cc=mb@smartsharesystems.com \
    --cc=stable@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.