From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 48BB046FF2 for ; Tue, 9 Dec 2025 17:41:27 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id ACA2440689; Tue, 9 Dec 2025 17:41:26 +0100 (CET) Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) by mails.dpdk.org (Postfix) with ESMTP id 8201D4067D for ; Tue, 9 Dec 2025 17:41:24 +0100 (CET) Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-4ed861eb98cso62419451cf.3 for ; Tue, 09 Dec 2025 08:41:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765298483; x=1765903283; darn=dpdk.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=ni5mjMi+U559kDQIoVrDTt7vIXwSyJVZYMfFV3IhkPY=; b=mPaz8c7dTFeQfM/DiObFszWGsm6EUgU4a+72Ceoulg6eBT01PfPQk93SdWoMXUc378 GF94E03w4TThsJsx7OqDYDdpuOeY1KW7hh8AFVlctzFiuHqXfpL70gTsEFrjD0EzH/eo UJN5tQJxdI95cQUpVSq2/qb0LiXKPIPijy8fbaBCMTHaaM7jZgHAacNz/+eoSaXNicao /G+sDtlXL0I90RTMaGl/RCtueRUCidJcWnSI4tk/YMX1tcVZgryOuxkz3q8fpv31MEHM i9dbgCXaNjvfDN0QpIh8IClQ7c+cektHnCdg1HjzRTwG1hqqtEzYY/C5L6RAarPm+J1O 8Fdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765298483; x=1765903283; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ni5mjMi+U559kDQIoVrDTt7vIXwSyJVZYMfFV3IhkPY=; b=NHr1wQgeJJduZohMBLto/fumOpBgMTKehEwLP6gCJ/VtzOFbE3zrK6zEOEYQvPIet4 clW9Numbz+vync/cZx6slvnHlT6gYtMdLXE2bS+yOBurr5iyqjz8ArO2ObWUjo4wCwk0 41uY8GGze4foC69d3dIPSIwJ2CbgWfgxpmAYHG69N3ywRaHAfpsrPl+imP4K1pnQE3HQ w9876vjf+BqPFQ4jJ8JTkAa3+oFhfXN3Lmny/P3UnX2MoKyiPqHjdz95YNKm51pI0acA F+E+FH91PxuIUd4i4uxNQwqhqDCavNtcUEXkndb/6mv8xLz+gz5rtRuSF+xDlJDJz1Sx 07Hw== X-Gm-Message-State: AOJu0Yz0kdDTI+YYdRe3SmTJnkgb9S4kV3KoDo1fUwabi7dF1ntv3T9D 8+95fL5YB5HfkgxbvdMBNDlbGGI9tw1TYXfP214bn96zFZp0bEjCT1+NSFImc20iEVx8Zr9d9D+ 3fS2VKxHS0oZrVsrxPeq//ANh0zKyCqWaI9vzIak= X-Gm-Gg: ASbGncsmxpr7d9RB7U/t+VDuy0H8NEJHH26gnzJbjqK08asPcpkM8Hj87E7WU7O2EJg Vhp1ZdvGbYb8w6d63AwQKNQ3pVR1udzUb93UNl9OJAf25M+7xIj8jeqaJJ1oN4f8i6/ChQ6Xkbq CvX5BEpdyfn1QxSX7a2SnP3F9YFjyqLZpsiKVFvulUi4jiAm7qpL3MQ96Oo+b9jsfj+fxKSZ8Fy uqd2uEyGbIFNpZATD6A3klWsXtZhCQ28uuZb24HZB4rgGnb7OKZqi608R7yZ9smMet/b6vd X-Google-Smtp-Source: AGHT+IFYamBLyF/Eo3ORpNnRMoO5H5SqlSRbpGt3wv7apcwJufzd1pNI7sAVwcm9VQnuu3yY+HV2QGR4bAi1M8lf+oI= X-Received: by 2002:a05:622a:155:b0:4ee:197a:e80a with SMTP id d75a77b69052e-4f03ff2c8c0mr179705591cf.77.1765298483500; Tue, 09 Dec 2025 08:41:23 -0800 (PST) MIME-Version: 1.0 From: narsimharaj pentam Date: Tue, 9 Dec 2025 22:11:11 +0530 X-Gm-Features: AQt7F2ocVWeayEoXQ3kYZWOX0K7lZ7oPN0K8naONFxqt77lMpF0OyHFIxzsEsUM Message-ID: Subject: Indirect mbuf handling To: users@dpdk.org Content-Type: multipart/alternative; boundary="0000000000000819bc06458795e0" X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --0000000000000819bc06458795e0 Content-Type: text/plain; charset="UTF-8" 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. Thanks. BR Narsimha --0000000000000819bc06458795e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0

I have a query rela= ted to ip fragmentation handling in=C2=A0DPDK.

The= DPDK application is trying to send a larger packet than the configured MTU= on the interface, before sending the packet to the =C2=A0i40e PMD the pack= et 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=C2= =A0 for a fragment , the indirect buffers will have reference to the mbu= f of the actual packet (zero copy).

The application will call fu= nction rte_eth_tx_burst to transmit fragments , which internally invokes i40e_xmit_pkts , the question here=C2=A0 is when should main applicati= on
mbuf should be freed , can It be freed immediately=C2=A0 after i40e_x= mit_pkts returns success, not sure because the mbuf's are queued up in = software ring before actual transmit,=C2=A0
I am worried about the frag= ments holding references to the main application buffer.

Thanks.

BR
Narsimha
--0000000000000819bc06458795e0--