Michał Kazior <kazikcz@xxxxxxxxx> writes: > On Thu, 29 Nov 2018 at 14:31, Toke Høiland-Jørgensen <toke@xxxxxxx> wrote: > [...] >> >> Option#3 is to say, Wifi XDP is so different that we should create a >> >> new (enum) bpf_prog_type. And then still see if we can leverage some >> >> of the same core-code (as long as it doesn't slowdown performance). >> >> >> > >> > Do you think that Option#3 will be more 'future-proof' respect to >> > Option#1? >> >> My feeling is that WiFi devices are not sufficiently different to >> warrant a whole new program type. We risk combinatorial explosion for >> all the stuff that is the same, but now need to be tested for two (or N) >> types... > > I'm not sure if my understanding is correct, but XDP seems like it can > (and intends to be able to?) act as a general purpose packet > accelerator (REDIRECT action was mentioned so I'm inferring..). In > such case you'll need to be able to perform transformations on packets > too, e.g. strip/prepend vlan tags, gre headers and what have you. The > 802.3 <-> 802.11 conversion could be treated on equal terms. Sure, that is perfectly possible. It just needs to be implemented by the eBPF program being loaded; and there is a facility to shrink/expand the packet size for encapsulation processing. It's just that since currently all interfaces process Ethernet frames, this frame type assumption has kinda been built in. So something needs to be done to handle that. The minimum is just to ignore the issue and make it up to the program writer to handle this or risk breaking things, but something a bit friendlier (such as an ability for the loaded program to indicate which frame type it is prepared to handle, which can be sanity-checked by the loader) might be a good idea... Especially if different WiFi devices will emit different frame types (so we can't just go "it's a WiFi device, you should know this"). Then there's the additional issue that since mac80211 and/or the driver may have internal state, we need to expose appropriate helpers for an XDP program to be able to update this as it's processing packets (before bypassing the stack, for instance). -Toke
