Question regarding duplicate fragment handling in DPDK IP reassembly library

[Samyak Jain]

 Can we fix it ?

Thanks & Regards,
Samyak Jain
Software Engineer
[cid:cb660601-cf07-4da8-aa47-acae8e4439c5]

________________________________
From: Stephen Hemminger <stephen at networkplumber.org>
Sent: Monday, June 15, 2026 11:07 PM
To: Samyak Jain <samyak.jain at amantyatech.com>
Cc: dev at dpdk.org <dev at dpdk.org>; Vikash kumar <vikash.kumar at amantyatech.com>; Ankur Bharadwaj <ankur.bharadwaj at amantyatech.com>
Subject: Re: Question regarding duplicate fragment handling in DPDK IP reassembly library

▲ CAUTION: This e-mail originated from OUTSIDE the organization. Please do not click links or open attachments from an unknown or suspicious origin.


On Mon, 15 Jun 2026 12:39:48 +0000
Samyak Jain <samyak.jain at amantyatech.com> wrote:

> Hi DPDK Community,
>
> I am using DPDK 25.11 and evaluating the IP reassembly library
> (librte_ip_frag).
>
> During testing, I observed that duplicate fragments appear to cause reassembly failure and the fragment context gets invalidated.
>
> I would like to know:
>
> 1. Is duplicate fragment handling intentionally unsupported in
>    rte_ipv4_frag_reassemble_packet() / rte_ipv6_frag_reassemble_packet()?
>
> 2. Has there been any upstream discussion or patch to support
>    duplicate fragments while still rejecting conflicting
>    fragments?
>
> 3. Are there any recommended approaches for applications that need
>    Linux-like duplicate fragment tolerance?
>
> Any guidance would be appreciated.
>
> Thanks & Regards,
> Samyak Jain
>

Short answer: yes it is buggy, no it shouldn't be.
Looking into it but not a simple answer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/dev/attachments/20260616/54dcffb2/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 3798 bytes
Desc: image.png
URL: <http://mails.dpdk.org/archives/dev/attachments/20260616/54dcffb2/attachment-0001.png>