> Lorenzo Bianconi <lorenzo.bianconi@xxxxxxxxxx> writes: > > >> 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' > > Yeah, a flag would be good; we've been discussing that for other XDP use > cases; it's not a done deal yet, but I think it would be useful. Do you think something wifi specific is ok (e.g bool wifi) or do you prefer something more general (e.g u32 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 > > How do you envision that will work with drivers that build software > 802.11 frames? The TX hook would have to be in mac80211 somewhere, > wouldn't it? In order to perform 802.3 --> 802.11 xdp forwarding my current idea is is to have ndo_xdp_xmit pointer in mac80211 that will forward the frame to the low-level driver (more or less what I did in the RFC series to upload the bpf program to mt76). We will probably need to pass some info to the driver from mac80211 (e.g sequence number or hw key idx to use) > > >> 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... Agree Regards, Lorenzo > > -Toke
