From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailfilter02.viettel.com.vn (mailfilter02.viettel.com.vn [125.235.240.54]) by dpdk.org (Postfix) with ESMTP id 9453C2C24; Fri, 23 Feb 2018 11:07:10 +0100 (CET) X-IronPort-AV: E=Sophos;i="5.47,382,1515430800"; d="scan'208";a="74084245" Received: from 125.235.240.45.adsl.viettel.vn (HELO mta2.viettel.com.vn) ([125.235.240.45]) by mailfilter02.viettel.com.vn with ESMTP; 23 Feb 2018 17:07:09 +0700 Received: from localhost (localhost [127.0.0.1]) by mta2.viettel.com.vn (Postfix) with ESMTP id CEE0F6897D6; Fri, 23 Feb 2018 17:07:04 +0700 (ICT) Received: from mta2.viettel.com.vn ([127.0.0.1]) by localhost (mta2.viettel.com.vn [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id kS95-V7W5MFL; Fri, 23 Feb 2018 17:07:04 +0700 (ICT) Received: from localhost (localhost [127.0.0.1]) by mta2.viettel.com.vn (Postfix) with ESMTP id A9A7D6896D8; Fri, 23 Feb 2018 17:07:04 +0700 (ICT) X-Virus-Scanned: amavisd-new at Received: from mta2.viettel.com.vn ([127.0.0.1]) by localhost (mta2.viettel.com.vn [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dfXqvrzxmQIl; Fri, 23 Feb 2018 17:07:04 +0700 (ICT) Received: from ANMLONGTB5 (unknown [27.68.241.28]) by mta2.viettel.com.vn (Postfix) with ESMTPSA id 62EBF689798; Fri, 23 Feb 2018 17:07:04 +0700 (ICT) To: , "'Victor Huertas'" Cc: , Message-ID: <003501d3ac8e$99fdd8c0$cdf98a40$@viettel.com.vn> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdOsjpmh9HCIqCU3QW2Ggoc+GqnfBQ== Content-Language: en-us MilterAction: FORWARD Date: Fri, 23 Feb 2018 17:07:04 +0700 (ICT) From: longtb5@viettel.com.vn Subject: [dpdk-dev] Suggestions on how to customize the metadata fields of each packet X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 10:07:11 -0000 Hi all, Victor, I suggest taking a closer look at section 7.1. here: http://dpdk.org/doc/guides/prog_guide/mbuf_lib.html The approach chosen by DPDK is to store everything, metadata and packet = data, in contiguous memory. That way, network packets will always have 1 = to 1 relationship with DPDK mbufs, no extra pointer needed. Every task = that you need to perform, from allocating, freeing, to transferring = mbufs to another lcore via software rings, are handled by DPDK. You = don't have to worry about them. You can save your metadata either = directly in the userdata field of struct rte_mbuf or in the headroom = area. I agree with Konstantin that in theory we should think of the userdata = field as space exclusively for metadata and reserve the headroom area = for packet header manipulation purposes only. However in practice I tend = to think that using headroom for metadata is more useful since you don't = really need to worry about any special configuration when creating mbuf = pool. The headroom is gonna be there by default and you can always = adjust its size after initialization. Please let me know if I missed = something. -BL > -----Original Message----- > From: konstantin.ananyev@intel.com = [mailto:konstantin.ananyev@intel.com] > Sent: Friday, February 23, 2018 4:27 PM > To: Victor Huertas ; longtb5@viettel.com.vn > Cc: dev@dpdk.org; users@dpdk.org > Subject: RE: [dpdk-dev] Suggestions on how to customize the metadata = fields > of each packet >=20 > Hi Victor, >=20 > > > > Thanks for your quick answer, > > > > I have read so many documents and web pages on this issue that > > probably I confounded the utility of the headroom. It is good to = know > > that this 128 bytes space is available to my disposal. The fact of > > being lost once the NIC transmits the frame it is not a problem at = all for my > application. > > However, in case that this space is not enough, I have seen in the > > rte_mbuf struct a (void *) pointer called userdata which is in = theory > > used for extra user-defined metadata. If I wanted to attach an > > additional metadata struct, I guess that I just have to assign the > > pointer to this struct to the userdata field. However, what happens = if > > I want that the content of this struct travels with the packet = through > > a software ring in order to be processed by another thread? Should I > > reserve more space in the ring to allocate such extra metadata? > > > > Thanks again, >=20 >=20 > In theory headroom inside mbuf should be left for packet's data. > To do things properly you'll need to create your mbuf mempools with > priv_size >=3D your_extra_metadata_size. >=20 > Konstantin >=20 > > > > PD: I have copied the message to users mailing list > > > > 2018-02-23 4:13 GMT+01:00 : > > > > > Hi, > > > > > > First, I think your question should be sent to the user mailing > > > list, not the dev mailing list. > > > > > > > I have seen that each packet has a headroom memory space (128 > > > > bytes > > > long) > > > > > > > where RSS hashing and other metadata provided by the NIC is = stored. > > > > > > If I=E2=80=99m not mistaken, the headroom is not where metadata = provided by > > > the NIC are stored. Those metadata are stored in the rte_mbuf > > > struct, which is also 128 bytes long. > > > > > > The headroom area is located AFTER the end of rte_mbuf (at offset = 128). > > > By default the headroom area is also 128 byte long, so the actual > > > packet data is stored at offset 256. > > > > > > You can store whatever you want in this headroom area. However = those > > > information are lost as soon as the packet leaves DPDK (the NIC = will > > > start sending at offset 256). > > > > > > -BL. > > > > > > > > > > > -- > > Victor