On 06/12, Toke Høiland-Jørgensen wrote: > Some immediate thoughts after glancing through this: > > > --- Use cases --- > > > > The goal of this series is to add two new standard-ish places > > in the transmit path: > > > > 1. Right before the packet is transmitted (with access to TX > > descriptors) > > 2. Right after the packet is actually transmitted and we've received the > > completion (again, with access to TX completion descriptors) > > > > Accessing TX descriptors unlocks the following use-cases: > > > > - Setting device hints at TX: XDP/AF_XDP might use these new hooks to > > use device offloads. The existing case implements TX timestamp. > > - Observability: global per-netdev hooks can be used for tracing > > the packets and exploring completion descriptors for all sorts of > > device errors. > > > > Accessing TX descriptors also means that the hooks have to be called > > from the drivers. > > > > The hooks are a light-weight alternative to XDP at egress and currently > > don't provide any packet modification abilities. However, eventually, > > can expose new kfuncs to operate on the packet (or, rather, the actual > > descriptors; for performance sake). > > dynptr? Haven't considered, let me explore, but not sure what it buys us here? > > --- UAPI --- > > > > The hooks are implemented in a HID-BPF style. Meaning they don't > > expose any UAPI and are implemented as tracing programs that call > > a bunch of kfuncs. The attach/detach operation happen via BPF syscall > > programs. The series expands device-bound infrastructure to tracing > > programs. > > Not a fan of the "attach from BPF syscall program" thing. These are part > of the XDP data path API, and I think we should expose them as proper > bpf_link attachments from userspace with introspection etc. But I guess > the bpf_mprog thing will give us that? bpf_mprog will just make those attach kfuncs return the link fd. The syscall program will still stay :-( > > --- skb vs xdp --- > > > > The hooks operate on a new light-weight devtx_frame which contains: > > - data > > - len > > - sinfo > > > > This should allow us to have a unified (from BPF POW) place at TX > > and not be super-taxing (we need to copy 2 pointers + len to the stack > > for each invocation). > > Not sure what I think about this one. At the very least I think we > should expose xdp->data_meta as well. I'm not sure what the use case for > accessing skbs is? If that *is* indeed useful, probably there will also > end up being a use case for accessing the full skb? skb_shared_info has meta_len, buf afaik, xdp doesn't use it. Maybe I a good opportunity to unify? Or probably won't work because if xdf_frame doesn't have frags, it won't have sinfo? > > --- Multiprog attachment --- > > > > Currently, attach/detach don't expose links and don't support multiple > > programs. I'm planning to use Daniel's bpf_mprog once it lands. > > > > --- TODO --- > > > > Things that I'm planning to do for the non-RFC series: > > - have some real device support to verify xdp_hw_metadata works > > Would be good to see some performance numbers as well :) +1 :-) > > - freplace > > - Documentation/networking/xdp-rx-metadata.rst - like documentation > > > > --- CC --- > > > > CC'ing people only on the cover letter. Hopefully can find the rest via > > lore. > > Well, I found it there, even though I was apparently left off the Cc > list :( > > -Toke Sure, I'll CC you explicitly next time! But I know you diligently follow bpf list, so decided to explicitly cc mostly netdev folks that might miss it otherwise.
