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
