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!
> > >
> >
