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.anan...@intel.com [mailto:konstantin.anan...@intel.com] > Sent: Friday, February 23, 2018 4:27 PM > To: Victor Huertas <vhuer...@gmail.com>; long...@viettel.com.vn > Cc: dev@dpdk.org; us...@dpdk.org > Subject: RE: [dpdk-dev] Suggestions on how to customize the metadata fields > of each packet > > Hi Victor, > > > > > 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, > > > 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 >= your_extra_metadata_size. > > Konstantin > > > > > PD: I have copied the message to users mailing list > > > > 2018-02-23 4:13 GMT+01:00 <long...@viettel.com.vn>: > > > > > 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’m 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
