> On Wed, 28 Nov 2018 13:36:26 +0100 > Toke Høiland-Jørgensen <toke@xxxxxxx> wrote: > > > 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? Hi Jesper, > > Today XDP assumes the frame is an Ethernet frame. With WiFi I guess > this assumption change, right? yes correct, SoftMAC devices report 802.11 frames to the stack > I worry a bit about this, as XDP is all about performance, and I don't > want to add performance regressions, by requiring all XDP programs or > core-code to having to check-frame-type before proceeding. That said, I > do think it is doable, without adding performance regressions. > > Option #1 is to move the check-frame-type to setup time. By either > having frame-type be part of eBPF prog, or supply frame-type as option > XDP attach call. And then reject attaching XDP prog to a device, where > the expected frame-type does not match. > I guess it will be enough to avoid loading a 'non-WiFi' bpf program on a 802.11 netdevice (and vice versa). We could add a flag (or something similar) in XDP_SETUP_PROG section of netdev_bpf data structure and use ieee80211_ptr netdevice pointer in order to guarantee that the bpf program will work on the expected 'frame-type' > Option#2, leave it up to eBPF-programmer if they want to add runtime > checks. By extending xdp_rxq_info with frame-type (default to > Ethernet), which allow the eBPF-programmer choose to write a generic > XDP program that both work on Ethernet and WiFi, or skip-check as they > know this will e.g. only run on Wifi. (Note xdp_rxq_info is static > read-only info per RX-queue, will all Wifi frames have same frame-type?. > 802.11 standards define three frame subtype (data, management and control). Subtypes could be detected parsing 802.11 header > > Also consider what happens in case of XDP_REDIRECT, from a Wifi NIC to > an Ethernet NIC. It would of-cause be cool to get this working cross, > Wifi-Ethernet. > Very cool :) On tx side the driver will accept standard ethernet frames in ndo_xdp_xmit pointer > 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? Regards, Lorenzo > -- > Best regards, > Jesper Dangaard Brouer > MSc.CS, Principal Kernel Engineer at Red Hat > LinkedIn: http://www.linkedin.com/in/brouer
