Re: A look into XDP hints for AF_XDP

["Desouza, Ederson" <ederson.desouza@intel.com>]

On Wed, 2021-07-07 at 15:26 -0700, Andrii Nakryiko wrote:
[snip]
> > > I don't follow, what is not working?
> > 
> > I get something like this:
> > 
> >   struct xdp_hints {
> >          yet_another_timestamp;
> >          rx_timestamp;
> >          tx_timestamp;
> >          hash32;
> >          extension_id;
> >          field_map;
> >   };
> 
> it could be due to corrupted BTF. Can you show output of
> 
> bpftool btf dump file /sys/kernel/btf/igc
> 
> (note no "format c").
> 

Errr... found out the issue on my side - this is a BTF described by
hand, and I didn't name the types - only defined their size and
bits_offset. Sorry for the noise!

> > 
> > Note how there's no type before the fields, one has to figure out if
> > `rx_timestamp` is u32 or u64.
> > 
> > 
> > > 
> > > > With the driver specific struct (or by using the generic one, if no
> > > > specific fields are needed), the application can then access the XDP
> > > > frame metadata. I've also added some helpers to aid getting the
> > > > metadata.
> > > > 
> > > > I added some examples on how to use those (they may be too simplistic),
> > > > so it's possible to get a feel on how this API might work.
> > > > 
> > > > My goals for this email are to check if this approach is valid and what
> > > > pitfalls can you see. I didn't send a patch series yet to not jump
> > > > ahead Alexandr and Michal work (I can rebase on top of their work
> > > > later) and because the igc RX and TX timestamp implementation I'm using
> > > > to provide more real looking data is not yet complete.
> > > > 
> > > > Another goal is to ensure that AF_XDP side is not forgotten in the XDP
> > > > hints discussion =D
> > > 
> > > Thanks for pointing that out :-)
> > > 
> > > > Naturally, if someone finds any issue trying those patches, please let
> > > > me know!
> > > 
> >