Lorenzo Bianconi <lorenzo.bianconi@xxxxxxxxxx> writes: >> Lorenzo Bianconi <lorenzo.bianconi@xxxxxxxxxx> writes: >> >> > This series is intended as a playground to start experimenting/developing >> > with XDP/eBPF over WiFi and collect ideas/concerns about it. >> > Introduce XDP support to mt76x2e/mt76x0e drivers. Currently supported >> > actions are: >> > - XDP_PASS >> > - XDP_ABORTED >> > - XDP_DROP >> > Introduce ndo_bpf mac80211 callback in order to to load a bpf >> > program into low level driver XDP rx hook. >> > This series has been tested through a simple bpf program (available here: >> > https://github.com/LorenzoBianconi/bpf-workspace/tree/master/mt76_xdp_stats) >> > used to count frame types received by the device. >> > Possible eBPF use cases could be: >> > - implement new statistics through bpf maps >> > - implement fast packet filtering (e.g in monitor mode) >> > - ... > > Hi Kalle, > >> >> This is most likely a stupid question, but why do this in the driver and >> not in mac80211 so that all drivers could benefit from it? I guess there >> are reasons for that, I just can't figure that out. XDP achieves its speedup by running the eBPF program inside the driver NAPI loop, before the kernel even touches the data in any other capacity (and in particular, before it allocates an SKB). Which kinda means the hook needs to be in the driver... Could be a fallback in mac80211, though; although we'd have to figure out how that interacts with Generic XDP. > This is an early stage implementation, at this point I would collect > other people opinions/concerns about using bpf/xdp directly on 802.11 > frames. Thanks for looking into this! I have two concerns with running XDP on 802.11 frames: 1. It makes it more difficult to add other XDP actions (such as REDIRECT), as the XDP program would then have to make sure that the outer packet headers are removed before, say, redirecting the packet out of an ethernet interface. Also, if we do add redirect, we would be bypassing mac80211 entirely; to what extent would that mess up internal state? 2. UI consistency; suddenly, the user needs to know which kind of frames to expect, and XDP program reuse becomes more difficult. This may be unavoidable given the nature of XDP, but some thought needs to go into this. Especially since we wouldn't necessarily be consistent between WiFi drivers (there are fullmac devices that remove 802.11 headers before sending up the frame, right?). Adding in Jesper; maybe he has some thoughts on this? -Toke
