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 A762B456C4 for ; Sat, 27 Jul 2024 06:08:42 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 228E440673; Sat, 27 Jul 2024 06:08:42 +0200 (CEST) Received: from agw.arknetworks.am (agw.arknetworks.am [79.141.165.80]) by mails.dpdk.org (Postfix) with ESMTP id 8742640274 for ; Sat, 27 Jul 2024 06:08:40 +0200 (CEST) Received: from debian (unknown [78.109.65.241]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by agw.arknetworks.am (Postfix) with ESMTPSA id 053A1E0A22; Sat, 27 Jul 2024 08:08:39 +0400 (+04) DKIM-Filter: OpenDKIM Filter v2.11.0 agw.arknetworks.am 053A1E0A22 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arknetworks.am; s=default; t=1722053320; bh=TGxxjIW7KS1NlVbneyLl72X2ngaTeuqgTZNue30884M=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=b6PbdTydK2NWMm6Qni8Hav8+N4psuEAZy9uJUFpIE52e8Gd2o3iqlNCm7M+O0NXS0 fJH1WUT3AWh9CxuZtS0Jq+Mxvd8ySbkcU909wxFAb88HqiNh74lonfUGsO1DJYCmBu S1UsLFnPWBQThIoQpn5zHB42kxuYjPYFOyPSSS1n+GZYWz2x3Q6s9dLYyPUrSe8rnP qcRuWbwUciGkonPJtmBoS5f4opLueV9zAACmvVvj14Zv6dJkMQGSlNoyKw0DYtC1ye lh1KAKCaRwGpRd+F5vhl5eXZcf6DjYqSxZmBzl9HhO8cU77LEImySwXGCCJGN9CaI8 AbN6gTAGlRQxw== Date: Sat, 27 Jul 2024 08:08:14 +0400 (+04) From: Ivan Malov To: "Lombardo, Ed" cc: "users@dpdk.org" Subject: Re: prepend mbuf to another mbuf In-Reply-To: Message-ID: <5e594cb0-5f6c-237d-12e0-d781a768325e@arknetworks.am> References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323328-303810266-1722053303=:6900" 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-303810266-1722053303=:6900 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Hi Ed, Tampering with reference counts seems peculiar. Why do that? I'd recommend you replace the manual prepend workflow that you have described with just one invocation of 'rte_pktmbuf_chain(mbuf_encap, mbuf_orig)' [1] or, if it's unfit for whatver reasons, make sure that the manual prepend code of yours does set correct 'pkt_len' in the new head mbuf and reset the same field in the original mbuf head. Will that work for you? Should you have further questions, please don't hesitate to ask. Thank you. [1] https://doc.dpdk.org/api-22.11/rte__mbuf_8h_source.html#l01758 On Fri, 26 Jul 2024, Lombardo, Ed wrote: > > Hi, > > I have an issue with retransmitting a received packet with encapsulation headers prepended to original received packet when using E810 NIC for transmit. > >   > > I have received a packet and is stored in one or more mbufs.  To do encapsulation I am acquiring a mbuf from free pool.  The new mbuf is where I add the L2 Header, IPv4 header and GRE > header.  I update the mbuf with rte_mbuf_refcnt_set(new_mbuf, 1) and rte_mbuf_refcnt_update(mbuf, 1); and then fill in the new mbuf metadata like (nb_segs, pkt_len, port, mbuf->next, > etc) from the original mbuf. > >   > > When I test this feature in VMWare with VMXNET3 vnic it works perfectly, the packet is transmitted with the encapsulation headers ahead of the original packet seen at the endpoint. > >   > > When I test same on Intel E810 only the first mbuf of data is transmitted, the original packet data from remaining mbufs is not transmitted. > >   > > I compared the mbufs just prior to transmit, byte by byte, in the VMXNET3 and E810 NIC cases and they are identical, the code path is the same. > > I also tried dpdk 17.11 and dpdk 22.11 versions with same results. > > Also same test fails with Intel X710 and X540 NICs similar to way E810 fails. > >   > > I modified the code to insert the encapsulation headers in the headroom of the original mbuf and it worked perfectly. > >   > > What could be the issue with the Intel NICs when transmitting a chain of mbufs, where the first mbuf has only the L2 header, IPv4 header and GRE header and remaining mbuf(s) contain the > original packet data? > >   > > Thanks, > > Ed > > > --8323328-303810266-1722053303=:6900--