RE: Indirect mbuf handling

["Morten Brørup" <mb@smartsharesystems.com>]

> From: narsimharaj pentam [mailto:pnarsimharaj@gmail.com] 
> Sent: Tuesday, 9 December 2025 18.05
> 
> Added dev group.
> 
> On Tue, Dec 9, 2025 at 10:11 PM narsimharaj pentam <pnarsimharaj@gmail.com> wrote:
> Hi 
> 
> I have a query related to ip fragmentation handling in DPDK.
> 
> The DPDK application is trying to send a larger packet than the configured MTU on the interface, before sending the packet to the  i40e PMD the packet will
> undergo fragmentation . The DPDK library function "rte_ipv4_fragment_packet" is used for fragmentation. Function rte_ipv4_fragment_packet will create
> direct and indirect mbuf's  for a fragment , the indirect buffers will have reference to the mbuf of the actual packet (zero copy).
> 
> The application will call function rte_eth_tx_burst to transmit fragments , which internally invokes i40e_xmit_pkts , the question here  is when should main application
> mbuf should be freed , can It be freed immediately  after i40e_xmit_pkts returns success, not sure because the mbuf's are queued up in software ring before actual transmit, 
> I am worried about the fragments holding references to the main application buffer.

The original packet can be freed immediately when then fragments have been created.

This is what the fragmentation example does:
https://elixir.bootlin.com/dpdk/v25.11/source/examples/ip_fragmentation/main.c#L289

This is what happens:
The original packet has a reference counter (which was incremented for each of the indirect mbufs referring to it), so freeing it at that point doesn't put it back in the pool.
When the last of the indirect mbufs is freed (by the driver called by rte_eth_tx_burst()), the original packet's reference counter reaches zero, and then the original mbuf is put back in the pool.

> 
> Thanks.
> 
> BR
> Narsimha