> Lorenzo Bianconi <lorenzo.bianconi@xxxxxxxxxx> writes: > > >> Lorenzo Bianconi <lorenzo.bianconi@xxxxxxxxxx> writes: > >> > >> >> On Wed, 28 Nov 2018 13:36:26 +0100 > >> >> Toke Høiland-Jørgensen <toke@xxxxxxx> wrote: > >> >> [...] > >> > > >> > 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)? > > My thought was a feature flag where the program can set a flag which > means "I expect 802.11 frames", and the driver can set a flag saying "I > emit 802.11 frames", and if those two flags don't match, the verifier > can refuse to load the program. This would not be fool-proof (an XDP > program can still corrupt things if written incorrectly), but it would > at least protect against the most obvious mistakes. I guess we can use iee80211_ptr in dev_xdp_install to double check if it is allowed to upload a 802.11 (or 802.3) bpf program > > >> >> 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) > > So this means that the driver will need to do the 802.11 encapsulation? > I guess we could have a fallback implementation in mac80211; but there > is possibly quite a bit of refactoring needed to make the existing code > work without an skb. Also, we need to think about queueing; I'm not sure > it's a good idea to have redirected frames bypass the TXQs... > good point :) Regards, Lorenzo > -Toke
