DPDK-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Konstantin Ananyev <konstantin.ananyev@huawei.com>
To: Stephen Hemminger <stephen@networkplumber.org>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: "stable@dpdk.org" <stable@dpdk.org>,
	Samyak Jain <samyak.jain@amantyatech.com>
Subject: RE: [PATCH 1/6] ip_frag: tolerate duplicate fragments
Date: Tue, 30 Jun 2026 08:08:46 +0000	[thread overview]
Message-ID: <de2ff0a594104b9b9cb4575f0ff4f8ed@huawei.com> (raw)
In-Reply-To: <20260616210656.464062-2-stephen@networkplumber.org>



> The reassembly code tracked only a running byte total and reserved slots
> for the first and last fragments, with no check for a fragment
> duplicating data already received. A single duplicate could destroy a
> recoverable datagram:
>  - a duplicate first or last fragment collided with the reserved slot and
>    sent the whole entry down the error path, freeing every collected
>    fragment;
>  - a duplicate intermediate fragment was appended to a new slot, inflating
>    frag_size past total_size so reassembly never completed.
> 
> RFC 791 reassembly tolerates duplicates: a fragment covering bytes
> already present carries no new information. Check for an exact duplicate
> (stored fragment with the same offset and length) and drop only that
> mbuf, before frag_size is updated, leaving the entry's accounting
> unchanged.
> 
> Overlapping fragments with differing bounds are a separate issue
> addressed in the next patch.
> 
> Fixes: cc8f4d020c0b ("examples/ip_reassembly: initial import")
> Cc: stable@dpdk.org

I am not sure it is a bug and needs to be propagated into the stable releases.
To me it is more like feature improvement.
BTW, as this and next patch does change the behavior and probably overall
performance numbers, - it probably worth to add a line in the release notes.
As another thought - it might be squashed with next patch in the series
(ip_frag: discard datagrams with overlapping fragments).
Apart from that:
Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>

> Reported-by: Samyak Jain <samyak.jain@amantyatech.com>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
>  lib/ip_frag/ip_frag_internal.c | 18 +++++++++++++++++-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/ip_frag/ip_frag_internal.c b/lib/ip_frag/ip_frag_internal.c
> index 382f42d0e1..9a03ef995a 100644
> --- a/lib/ip_frag/ip_frag_internal.c
> +++ b/lib/ip_frag/ip_frag_internal.c
> @@ -89,7 +89,23 @@ struct rte_mbuf *
>  ip_frag_process(struct ip_frag_pkt *fp, struct rte_ip_frag_death_row *dr,
>  	struct rte_mbuf *mb, uint16_t ofs, uint16_t len, uint16_t more_frags)
>  {
> -	uint32_t idx;
> +	uint32_t i, idx;
> +
> +	/*
> +	 * Discard an exact duplicate fragment. If a previously stored fragment
> +	 * already covers the same offset and length, this fragment carries no
> +	 * new data. Reassembly is tolerant of duplicates (RFC 791), so drop
> +	 * only this mbuf and keep the reassembly entry intact rather than
> +	 * treating it as an error. Fragments overlapping an existing one with
> +	 * different bounds are not handled here.
> +	 */
> +	for (i = 0; i != fp->last_idx; i++) {
> +		if (fp->frags[i].mb != NULL && fp->frags[i].ofs == ofs &&
> +				fp->frags[i].len == len) {
> +			IP_FRAG_MBUF2DR(dr, mb);
> +			return NULL;
> +		}
> +	}
> 
>  	fp->frag_size += len;
> 
> --
> 2.53.0


  reply	other threads:[~2026-06-30  8:08 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-16 21:05 [PATCH 0/6] ip_frag: fix reassembly defects and add test Stephen Hemminger
2026-06-16 21:05 ` [PATCH 1/6] ip_frag: tolerate duplicate fragments Stephen Hemminger
2026-06-30  8:08   ` Konstantin Ananyev [this message]
2026-06-30 13:32     ` Stephen Hemminger
2026-06-16 21:05 ` [PATCH 2/6] ip_frag: discard datagrams with overlapping fragments Stephen Hemminger
2026-06-19 13:12   ` Morten Brørup
2026-06-19 17:01     ` Stephen Hemminger
2026-06-22 15:01       ` Morten Brørup
2026-06-22 15:03         ` Stephen Hemminger
2026-06-30  8:16   ` Konstantin Ananyev
2026-06-16 21:05 ` [PATCH 3/6] ip_frag: include protocol in IPv4 reassembly key Stephen Hemminger
2026-06-30  8:17   ` Konstantin Ananyev
2026-06-16 21:05 ` [PATCH 4/6] ip_frag: drop IPv6 fragments with unexpected headers Stephen Hemminger
2026-06-30  9:21   ` Konstantin Ananyev
2026-06-16 21:05 ` [PATCH 5/6] ip_frag: reject oversized reassembled datagrams Stephen Hemminger
2026-06-30  9:32   ` Konstantin Ananyev
2026-06-16 21:05 ` [PATCH 6/6] app/test: add test for IP reassembly Stephen Hemminger
2026-06-19 13:24 ` [PATCH 0/6] ip_frag: fix reassembly defects and add test Morten Brørup
2026-06-22 15:03 ` Morten Brørup
2026-06-30 15:36 ` [PATCH v2 0/8] " Stephen Hemminger
2026-06-30 15:36   ` [PATCH v2 1/8] ip_frag: tolerate duplicate fragments Stephen Hemminger
2026-06-30 15:36   ` [PATCH v2 2/8] ip_frag: discard datagrams with overlapping fragments Stephen Hemminger
2026-07-01  8:13     ` Konstantin Ananyev
2026-06-30 15:36   ` [PATCH v2 3/8] ip_frag: include protocol in IPv4 reassembly key Stephen Hemminger
2026-06-30 15:36   ` [PATCH v2 4/8] ip_frag: drop IPv6 fragments with per-fragment headers Stephen Hemminger
2026-06-30 15:36   ` [PATCH v2 5/8] ip_frag: reject oversized reassembled datagrams Stephen Hemminger
2026-06-30 15:36   ` [PATCH v2 6/8] app/test: add test for IP reassembly Stephen Hemminger
2026-06-30 15:36   ` [PATCH v2 7/8] ip_frag: remove use of rte_memcpy Stephen Hemminger
2026-06-30 15:36   ` [PATCH v2 8/8] doc: add release note about ip_frag changes Stephen Hemminger
2026-06-30 19:19     ` Stephen Hemminger
2026-07-01  8:22     ` Konstantin Ananyev
2026-07-01 16:20 ` [PATCH v3 0/8] ip_frag: fix reassembly defects and add test Stephen Hemminger
2026-07-01 16:20   ` [PATCH v3 1/8] ip_frag: tolerate duplicate fragments Stephen Hemminger
2026-07-01 16:20   ` [PATCH v3 2/8] ip_frag: discard datagrams with overlapping fragments Stephen Hemminger
2026-07-01 16:20   ` [PATCH v3 3/8] ip_frag: include protocol in IPv4 reassembly key Stephen Hemminger
2026-07-01 16:20   ` [PATCH v3 4/8] ip_frag: drop IPv6 fragments with per-fragment headers Stephen Hemminger
2026-07-01 16:52     ` Konstantin Ananyev
2026-07-01 16:20   ` [PATCH v3 5/8] ip_frag: reject oversized reassembled datagrams Stephen Hemminger
2026-07-01 16:20   ` [PATCH v3 6/8] app/test: add test for IP reassembly Stephen Hemminger
2026-07-01 16:20   ` [PATCH v3 7/8] ip_frag: remove use of rte_memcpy Stephen Hemminger
2026-07-01 16:53     ` Konstantin Ananyev
2026-07-01 16:20   ` [PATCH v3 8/8] doc: add release note about ip_frag changes Stephen Hemminger
2026-07-01 16:42     ` Konstantin Ananyev
2026-07-02 20:55   ` [PATCH v3 0/8] ip_frag: fix reassembly defects and add test Thomas Monjalon

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=de2ff0a594104b9b9cb4575f0ff4f8ed@huawei.com \
    --to=konstantin.ananyev@huawei.com \
    --cc=dev@dpdk.org \
    --cc=samyak.jain@amantyatech.com \
    --cc=stable@dpdk.org \
    --cc=stephen@networkplumber.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox