A look into XDP hints for AF_XDP

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

Hi,

Following current discussions around XDP hints, it's clear that
currently the focus is on BPF applications. But my interest is in the
AF_XDP side of things - user space applications.

In there, there's not much help from BPF CO-RE - who's going to rewrite
user space structs, after all? So, I decided to give a try at a
possible implementation, using igc driver as I'm more used to it, and
come here ask some questions about it.

For the curious, here's my branch with current work:

https://github.com/edersondisouza/linux/tree/xdp-hints

It's on top of Alexandr Lobakin and Michal Swiatkowski work - but I
decided to incorporate some of the CO-RE related feedback, so I could
have something that also works with BPF applications. Please not that
I'm not trying to jump ahead of them in incorporating the feedback -
probably they have something more robust here - but if you see some
value in my patches, feel free to reuse/incorporate them (if they are
just an example of what not to do, it's still an example =D ).
I also added some XDP ZC patches for igc that are still moving to
mainline.

In there, I basically defined a sample of "generic hints", that is
basically an struct with common hints, such as RX and TX timestamp,
hash, etc. I also included two more members to that struct: field_map
and extension_id. The first, shows which members are actually valid in
the data, the second is an arbitrary id that drivers can use to say
"there's extra data" beyond the generic members, and how to interpret
what's there is driver specific. A BTF is also created to represent
this struct, and registering is done the same way Saeed's patch did.

User space developers that need to get the struct can use something
like to get it from the driver:

  # tools/bpf/bpftool/bpftool net xdp show
  xdp:
  enp6s0(5) md_btf_id(60) md_btf_enabled(1)

And use the btf_id to get the struct:

  # bpftool btf dump file /sys/kernel/btf/igc format c

Currently though, that's bad - as in this case the struct has no types,
only the field names. Why?

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

Naturally, if someone finds any issue trying those patches, please let
me know!

Thanks!
-- 
Ederson de Souza