Re: [dpdk-users] Suggestions on how to customize the metadata fields of each packet

Re: [dpdk-users] Suggestions on how to customize the metadata fields of each packet

[Victor Huertas]

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,

PD: I have copied the message to users mailing list

2018-02-23 4:13 GMT+01:00 <longtb5@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

Re: [dpdk-users] [dpdk-dev] Suggestions on how to customize the metadata fields of each packet

[Ananyev, Konstantin]

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 <longtb5@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