Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
> On Mon, 2018-12-03 at 21:36 +0200, Toke Høiland-Jørgensen wrote: > > Hi Johannes > > > > I think your email can be basically summed up to: > > > > > [ ... ] but really I think it's a can of worms. > > > > ...right? :) > > Heh, yeah :) > > > I sort of had a feeling it would be, but thank you for spelling out in > > excruciating detail why that is so. > > :-) > > > Given this, I think I agree that it's not worth it for now, and we > > should hold off on adding XDP support until we have 802.3/.11 conversion > > offload working... Which I think is also where you ended up? :) > > That case is at least easy, yeah. And it seems kinda likely that we'll > end up with that in all well-maintained drivers in the relatively near > future anyway? Hi all, thanks for sharing your thoughts and concerns, as already stated the main goal of this series is get feedbacks and/or blocking points to start experimenting with eBPF over 802.11 devices. Reviewing the points indicated by Johannes, 802.11 protocol is too complicated to be managed without skb allocation. I agree that for the moment XDP/eBPF can be useful for devices that supports hw offloading (or FullMac devices?) since all the tricky aspects are already managed in the firmware and we can take care of XDP stuff. Probably in the near future we will respin this argument :) > > BTW, in a sense I still kind of want to add eBPF to the mac80211 ingress > path, just not in the XDP sense. For example, I had a proposal a while > ago to add a filter to the monitor mode RX path(s) in eBPF; I still > think that's useful. > > I also think it may be useful to put eBPF programs into per-netdev > ingress path, in order to e.g. collect statistics, rather than hard- > coding all kinds of statistics into mac80211. > > All of these things I consider absolutely useful and helpful. I like > eBPF and the flexibility it affords. I just really don't think we should > call it XDP or let it do similar things to XDP like dropping or > redirecting frames. > +1 :) Regards, Lorenzo > johannes >
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
Johannes Berg writes: > On Mon, 2018-12-03 at 21:36 +0200, Toke Høiland-Jørgensen wrote: >> Hi Johannes >> >> I think your email can be basically summed up to: >> >> > [ ... ] but really I think it's a can of worms. >> >> ...right? :) > > Heh, yeah :) > >> I sort of had a feeling it would be, but thank you for spelling out in >> excruciating detail why that is so. > > :-) > >> Given this, I think I agree that it's not worth it for now, and we >> should hold off on adding XDP support until we have 802.3/.11 >> conversion offload working... Which I think is also where you ended >> up? :) > > That case is at least easy, yeah. And it seems kinda likely that we'll > end up with that in all well-maintained drivers in the relatively near > future anyway? Right; you probably know that better than me :) > BTW, in a sense I still kind of want to add eBPF to the mac80211 ingress > path, just not in the XDP sense. For example, I had a proposal a while > ago to add a filter to the monitor mode RX path(s) in eBPF; I still > think that's useful. > > I also think it may be useful to put eBPF programs into per-netdev > ingress path, in order to e.g. collect statistics, rather than hard- > coding all kinds of statistics into mac80211. > > All of these things I consider absolutely useful and helpful. I like > eBPF and the flexibility it affords. I just really don't think we should > call it XDP or let it do similar things to XDP like dropping or > redirecting frames. Absolutely; totally on board with that! -Toke
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
On Mon, 2018-12-03 at 21:36 +0200, Toke Høiland-Jørgensen wrote: > Hi Johannes > > I think your email can be basically summed up to: > > > [ ... ] but really I think it's a can of worms. > > ...right? :) Heh, yeah :) > I sort of had a feeling it would be, but thank you for spelling out in > excruciating detail why that is so. :-) > Given this, I think I agree that it's not worth it for now, and we > should hold off on adding XDP support until we have 802.3/.11 conversion > offload working... Which I think is also where you ended up? :) That case is at least easy, yeah. And it seems kinda likely that we'll end up with that in all well-maintained drivers in the relatively near future anyway? BTW, in a sense I still kind of want to add eBPF to the mac80211 ingress path, just not in the XDP sense. For example, I had a proposal a while ago to add a filter to the monitor mode RX path(s) in eBPF; I still think that's useful. I also think it may be useful to put eBPF programs into per-netdev ingress path, in order to e.g. collect statistics, rather than hard- coding all kinds of statistics into mac80211. All of these things I consider absolutely useful and helpful. I like eBPF and the flexibility it affords. I just really don't think we should call it XDP or let it do similar things to XDP like dropping or redirecting frames. johannes
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
Hi Johannes I think your email can be basically summed up to: > [ ... ] but really I think it's a can of worms. ...right? :) I sort of had a feeling it would be, but thank you for spelling out in excruciating detail why that is so. Given this, I think I agree that it's not worth it for now, and we should hold off on adding XDP support until we have 802.3/.11 conversion offload working... Which I think is also where you ended up? :) -Toke
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
Hi Toke, all, Sorry I wasn't around for the discussion, I've been travelling and sick. I'm picking this as an arbitrary point in the discussion to reply to, hope you don't feel bad about that. >> [A-MPDU reordering] > In principle, all of this could be done. But we need to think carefully > about what things it really makes sense to offload to XDP. In the > general case, we will end up re-implementing all of mac80211 in eBPF, > which is obviously not ideal. Agree with this, completely. Mind you, it's not even simple to do that, because each kind of hardware behaves differently. See below. > For crypto in particular, I wonder if there is much of a speedup to be > had if the crypto is in software anyway. Wouldn't that dominate the > processing time? Yeah, I'd also think the cost of skb allocation is dwarfed by the cost of doing the crypto, but not really sure, maybe you have a fast special AES instruction? :) Anyway, here are my thoughts after reading most of the thread and having discussed it with Lorenzo a while back and today: 1) I'm going to restrict most of the discussion to mac80211, but there are interesting cases outside of it as well. Much of the same arguments apply, though it means *more* feature combinatorial explosion to be able to handle everything. 2) We don't yet have it (but it's been suggested for years and we might also get it on Intel hardware eventually), but if we have TX and/or RX 802.3/802.11 frame conversion offload then I think we have no argument - XDP applies pure and simple as is in each direction you have offloads for, unless you do something really stupid in HW like still having to do reorder buffer or PN checking based on RX frame metadata. I hope nobody does that, but then I suppose you could do it before the XDP hooks w/o allocating SKBs. 3) TX from XDP (i.e. X -> wifi) could be implemented in mac80211, but is subject to some rather iffy details, for example: a) mac80211 may need more headroom than the input has, do we have to copy the whole data? depending on xdp_mem_type I think we may need that, rather than being able to make an skb with frag pages and extra headroom? We don't know it was just a single page and I guess we can't ref that page anyway, but maybe we could meddle with the SKB frag data somehow to avoid that. b) mac80211 may need to software encrypt - copy the whole data c) lifetime issues - we need to call xdp_return_frame(), which I guess we can tie to the skb we'd create anyway [2] (and IMHO we need to allocate an skb anyway, due to TXQs like Toke mentioned and much other possible software handling) 4) XDP during RX - well, that's _mostly_ what this thread has been about, but really I think it's a can of worms. Consider: a) drivers may or may not do SW decryption b) drivers may or may not do PN checking - so your XDP program might end up having to do that or risk security/replay bugs! (which, btw, you can only do after reordering so see below) c) drivers may or may not do A-MSDU deaggregation, do you[1] really want to handle that in XDP? You could argue outer code should walk over the subframes, but then dropping becomes hard - and this really should only happen after a) and b) Oh, and IIRC there are cases that use A-MSDUs for single frames just to encapsulate different MAC addresses. Speaking of which, you have to validate the inner MAC addresses (but it's not a trivial comparison) or risk security bugs again. d) drivers may or may not do A-MPDU reordering (this was discussed earlier in the thread), which means even if you drop a frame you haven't just affected that connection but potentially stalled everything until the reorder buffer times out (~100ms), or we need a way for mac80211 to insert a fake skb into the reorder buffer at that spot (but then you allocate an skb again and high-speed traffic where you'd care most is always in an A-MPDU session) e) speaking of which, Intel's device has hardware assist things for reordering, but not fully offloaded reordering, so you might end up with hardware-specific ways of doing this in XDP? f) Some data frames are used internally in the stack, e.g. for TDLS. g) data frames may also affect the powersave state of a station, so if you have e.g. ath9k and the station sends a frame to wake up, but you decide you XDP_DROP it, the powersave state will get messed up, unless ... special handling (either mac80211 or the bpf program) again. Also, U-APSD. h) There are also simple things like QoS/non-QoS that add to the combinatorial explosion of things you have to handle i) data frames could be sent by anyone, not just STAs connected to your network, so I guess you'd have to filter that and mac80211 would have to expose a station table lookup helper or
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
Michał Kazior writes: > On Thu, 29 Nov 2018 at 14:00, Lorenzo Bianconi > wrote: > [...] >> > The other direction will probably be more difficult, at least if 802.11 >> > frames need to be built in software. It *might* be possible with the XDP >> > egress hook we are planning (with a suitable set of helpers, the eBPF >> > program could build the 802.11 frames), but I'm not really sure if that >> > is worth doing as I'm quite sure there are some hairy edge cases >> > there... >> >> The possible issue with XDP_DROP action you are referring to here is A-MPDU >> reordering on rx side, right? If so I guess the issue will be fixed by >> tid_agg_rx->reorder_timer. Are you referring to other possible edge cases? > > What I'm thinking is reordering could be one of possible things to > offload to an XDP program. It would require per-station data structure > to keep track of the frame sequence numbers (among other things). Same > could be said for crypto offloads (would require XDP programs to be > able to use crypto apis I guess?). In principle, all of this could be done. But we need to think carefully about what things it really makes sense to offload to XDP. In the general case, we will end up re-implementing all of mac80211 in eBPF, which is obviously not ideal. However, fast-path handling in XDP, which will punt to the full stack on edge cases, is probably doable (and is the general model we envision for XDP programs). For crypto in particular, I wonder if there is much of a speedup to be had if the crypto is in software anyway. Wouldn't that dominate the processing time? Whereas, if the crypto is offloaded to hardware, fast-path packet processing in XDP might make sense. This would translate to the fallback mode I mention above: If hardware crypto is enabled, handle in XDP fast-path, otherwise punt to mac80211 for full (crypto) processing. -Toke
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
On Thu, 29 Nov 2018 at 14:00, Lorenzo Bianconi wrote: [...] > > The other direction will probably be more difficult, at least if 802.11 > > frames need to be built in software. It *might* be possible with the XDP > > egress hook we are planning (with a suitable set of helpers, the eBPF > > program could build the 802.11 frames), but I'm not really sure if that > > is worth doing as I'm quite sure there are some hairy edge cases > > there... > > The possible issue with XDP_DROP action you are referring to here is A-MPDU > reordering on rx side, right? If so I guess the issue will be fixed by > tid_agg_rx->reorder_timer. Are you referring to other possible edge cases? What I'm thinking is reordering could be one of possible things to offload to an XDP program. It would require per-station data structure to keep track of the frame sequence numbers (among other things). Same could be said for crypto offloads (would require XDP programs to be able to use crypto apis I guess?). Michał
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
Lorenzo Bianconi writes: >> Lorenzo Bianconi writes: >> >> > On Nov 28, Toke Høiland-Jørgensen wrote: >> >> Lorenzo Bianconi writes: >> >> >> >> >> Lorenzo Bianconi 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! >> >> >> > >> >> >> > Hi Toke, >> >> >> > >> >> >> >> >> >> >> >> 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? >> >> >> >> >> >> >> > >> >> >> > You are right, my assumption here is the logic/complexity is moved to >> >> >> > the bpf program that needs to take care of all possible issues that >> >> >> > can be introduced. More or less it is the same if a bpf program mess >> >> >> > up with TCP segments on a wired connection, isn't it? >> >> >> >> >> >> No, I guess not; except here it potentially applies to all packets >> >> >> (things like BAW tracking), and it is *in addition* to TCP. >> >> > >> >> > Yes, here it is a little bit harder, but I was meaning that the bpf >> >> > program >> >> > has to be very careful when dropping a packet :) >> >> >> >> Yeah. What kind of filtering were you thinking you would use this for in >> >> the short term? >> >> >> > >> > When I started working on XDP for mt76 I was thinking about BSSID >> > filtering but I was looking for a more general solution respect to add >> > that feature in the driver. Moreover we could use bpf for fast packet >> > filtering when you add an interface in monitor mode. >> >> Yup, both of these make sense. >> >> > Nevertheless I guess there could be other use cases not limited to >> > frame filtering. My primary goal with this series is to collect >> > ideas/concerns on WiFi XDP/eBPF possible uses cases. >> >> Well, Michał's idea about offloading is cool if it is possible to get >> vendors to implement it. >> > > Yep, would be very cool :) > >> Other than that, if we can solve the issues with differences between >> 802.11 and plain Ethernet frames, I see no reason why it wouldn't be >> possible to implement an XDP fast-path for WiFi-to-Ethernet forwarding, >> which might be useful in an access point, especially as WiFi speeds >> increase. >> > > Agree > >> The other direction will probably be more difficult, at least if 802.11 >> frames need to be built in software. It *might* be possible with the XDP >> egress hook we are planning (with a suitable set of helpers, the eBPF >> program could build the 802.11 frames), but I'm not really sure if that
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
> Lorenzo Bianconi writes: > > > On Nov 28, Toke Høiland-Jørgensen wrote: > >> Lorenzo Bianconi writes: > >> > >> >> Lorenzo Bianconi 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! > >> >> > > >> >> > Hi Toke, > >> >> > > >> >> >> > >> >> >> 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? > >> >> >> > >> >> > > >> >> > You are right, my assumption here is the logic/complexity is moved to > >> >> > the bpf program that needs to take care of all possible issues that > >> >> > can be introduced. More or less it is the same if a bpf program mess > >> >> > up with TCP segments on a wired connection, isn't it? > >> >> > >> >> No, I guess not; except here it potentially applies to all packets > >> >> (things like BAW tracking), and it is *in addition* to TCP. > >> > > >> > Yes, here it is a little bit harder, but I was meaning that the bpf > >> > program > >> > has to be very careful when dropping a packet :) > >> > >> Yeah. What kind of filtering were you thinking you would use this for in > >> the short term? > >> > > > > When I started working on XDP for mt76 I was thinking about BSSID > > filtering but I was looking for a more general solution respect to add > > that feature in the driver. Moreover we could use bpf for fast packet > > filtering when you add an interface in monitor mode. > > Yup, both of these make sense. > > > Nevertheless I guess there could be other use cases not limited to > > frame filtering. My primary goal with this series is to collect > > ideas/concerns on WiFi XDP/eBPF possible uses cases. > > Well, Michał's idea about offloading is cool if it is possible to get > vendors to implement it. > Yep, would be very cool :) > Other than that, if we can solve the issues with differences between > 802.11 and plain Ethernet frames, I see no reason why it wouldn't be > possible to implement an XDP fast-path for WiFi-to-Ethernet forwarding, > which might be useful in an access point, especially as WiFi speeds > increase. > Agree > The other direction will probably be more difficult, at least if 802.11 > frames need to be built in software. It *might* be possible with the XDP > egress hook we are planning (with a suitable set of helpers, the eBPF > program could build the 802.11 frames), but I'm not really sure if that > is worth doing as I'm quite sure there are some hairy edge cases > there... The possible issue with XDP_DROP action you are referring to here
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
Lorenzo Bianconi writes: > On Nov 28, Toke Høiland-Jørgensen wrote: >> Lorenzo Bianconi writes: >> >> >> Lorenzo Bianconi 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! >> >> > >> >> > Hi Toke, >> >> > >> >> >> >> >> >> 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? >> >> >> >> >> > >> >> > You are right, my assumption here is the logic/complexity is moved to >> >> > the bpf program that needs to take care of all possible issues that >> >> > can be introduced. More or less it is the same if a bpf program mess >> >> > up with TCP segments on a wired connection, isn't it? >> >> >> >> No, I guess not; except here it potentially applies to all packets >> >> (things like BAW tracking), and it is *in addition* to TCP. >> > >> > Yes, here it is a little bit harder, but I was meaning that the bpf program >> > has to be very careful when dropping a packet :) >> >> Yeah. What kind of filtering were you thinking you would use this for in >> the short term? >> > > When I started working on XDP for mt76 I was thinking about BSSID > filtering but I was looking for a more general solution respect to add > that feature in the driver. Moreover we could use bpf for fast packet > filtering when you add an interface in monitor mode. Yup, both of these make sense. > Nevertheless I guess there could be other use cases not limited to > frame filtering. My primary goal with this series is to collect > ideas/concerns on WiFi XDP/eBPF possible uses cases. Well, Michał's idea about offloading is cool if it is possible to get vendors to implement it. Other than that, if we can solve the issues with differences between 802.11 and plain Ethernet frames, I see no reason why it wouldn't be possible to implement an XDP fast-path for WiFi-to-Ethernet forwarding, which might be useful in an access point, especially as WiFi speeds increase. The other direction will probably be more difficult, at least if 802.11 frames need to be built in software. It *might* be possible with the XDP egress hook we are planning (with a suitable set of helpers, the eBPF program could build the 802.11 frames), but I'm not really sure if that is worth doing as I'm quite sure there are some hairy edge cases there... -Toke
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
On Nov 28, Toke Høiland-Jørgensen wrote: > Lorenzo Bianconi writes: > > >> Lorenzo Bianconi 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! > >> > > >> > Hi Toke, > >> > > >> >> > >> >> 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? > >> >> > >> > > >> > You are right, my assumption here is the logic/complexity is moved to > >> > the bpf program that needs to take care of all possible issues that > >> > can be introduced. More or less it is the same if a bpf program mess > >> > up with TCP segments on a wired connection, isn't it? > >> > >> No, I guess not; except here it potentially applies to all packets > >> (things like BAW tracking), and it is *in addition* to TCP. > > > > Yes, here it is a little bit harder, but I was meaning that the bpf program > > has to be very careful when dropping a packet :) > > Yeah. What kind of filtering were you thinking you would use this for in > the short term? > When I started working on XDP for mt76 I was thinking about BSSID filtering but I was looking for a more general solution respect to add that feature in the driver. Moreover we could use bpf for fast packet filtering when you add an interface in monitor mode. Nevertheless I guess there could be other use cases not limited to frame filtering. My primary goal with this series is to collect ideas/concerns on WiFi XDP/eBPF possible uses cases. Regards, Lorenzo > -Toke
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
Lorenzo Bianconi writes: >> Lorenzo Bianconi 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! >> > >> > Hi Toke, >> > >> >> >> >> 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? >> >> >> > >> > You are right, my assumption here is the logic/complexity is moved to >> > the bpf program that needs to take care of all possible issues that >> > can be introduced. More or less it is the same if a bpf program mess >> > up with TCP segments on a wired connection, isn't it? >> >> No, I guess not; except here it potentially applies to all packets >> (things like BAW tracking), and it is *in addition* to TCP. > > Yes, here it is a little bit harder, but I was meaning that the bpf program > has to be very careful when dropping a packet :) Yeah. What kind of filtering were you thinking you would use this for in the short term? -Toke
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
> Lorenzo Bianconi 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! > > > > Hi Toke, > > > >> > >> 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? > >> > > > > You are right, my assumption here is the logic/complexity is moved to > > the bpf program that needs to take care of all possible issues that > > can be introduced. More or less it is the same if a bpf program mess > > up with TCP segments on a wired connection, isn't it? > > No, I guess not; except here it potentially applies to all packets > (things like BAW tracking), and it is *in addition* to TCP. Yes, here it is a little bit harder, but I was meaning that the bpf program has to be very careful when dropping a packet :) > > >> 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?). > >> > > > > Right, maybe can we have some kind of 'wifi' bpf helpers? > > Yeah, I guess we would at least need helpers to update any internal > state in mac80211 (such as BAW), or BPF programs wouldn't even be able > to drop packets without messing things up... > Correct. Regards, Lorenzo > -Toke
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
Lorenzo Bianconi 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! > > Hi Toke, > >> >> 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? >> > > You are right, my assumption here is the logic/complexity is moved to > the bpf program that needs to take care of all possible issues that > can be introduced. More or less it is the same if a bpf program mess > up with TCP segments on a wired connection, isn't it? No, I guess not; except here it potentially applies to all packets (things like BAW tracking), and it is *in addition* to TCP. >> 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?). >> > > Right, maybe can we have some kind of 'wifi' bpf helpers? Yeah, I guess we would at least need helpers to update any internal state in mac80211 (such as BAW), or BPF programs wouldn't even be able to drop packets without messing things up... -Toke
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
Michał Kazior writes: > On Wed, 28 Nov 2018 at 13:39, Toke Høiland-Jørgensen > wrote:[...] >> > 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'm really hyped up with this especially when I think this could be > maybe offloaded to wlan cpu's for e.g. deep powersaving (allow host > system to suspend) without relying on blackbox logic you get today, or > 802.11 -> 802.3 conversion (to offload host cpu). Yeah, good point! >> 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?). > > Yep - you can expect 802.3 frames or amsdu subframes (DA+SA+length) > too. In some cases you could also expect internal events (broadcom if > I understand their fullmac arch). Oh boy. I figured it was going to be a can of worms; didn't realise it was quite that big :/ -Toke
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
> >> > 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! Hi Toke, > > 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? > You are right, my assumption here is the logic/complexity is moved to the bpf program that needs to take care of all possible issues that can be introduced. More or less it is the same if a bpf program mess up with TCP segments on a wired connection, isn't it? > 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?). > Right, maybe can we have some kind of 'wifi' bpf helpers? Regards, Lorenzo > > Adding in Jesper; maybe he has some thoughts on this? > > -Toke
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
On Wed, 28 Nov 2018 at 13:39, Toke Høiland-Jørgensen wrote:[...] > > 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'm really hyped up with this especially when I think this could be maybe offloaded to wlan cpu's for e.g. deep powersaving (allow host system to suspend) without relying on blackbox logic you get today, or 802.11 -> 802.3 conversion (to offload host cpu). > 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?). Yep - you can expect 802.3 frames or amsdu subframes (DA+SA+length) too. In some cases you could also expect internal events (broadcom if I understand their fullmac arch). Michał
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
Lorenzo Bianconi writes: >> Lorenzo Bianconi 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
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
> Lorenzo Bianconi 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. > > -- > Kalle Valo I thought about that possibility (and I think it is definitely valuable) but I preferred to work as close as possible to the hw running the bpf program before skb allocation. My primary goal when I started thinking about eBPF over WiFi was to perform fast packet filtering. I think these two possibility are not mutually exclusive, we can fall-back to mac80211 if hw driver does not support 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. Regards, Lorenzo
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
Lorenzo Bianconi 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) > - ... 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. -- Kalle Valo
[RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
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) - ... Lorenzo Bianconi (5): mac80211: introduce ieee80211_xdp handler mac80211: introduce ieee80211_vif_to_netdev routine mt76: split mt76_dma_rx_reset in init_rx_reset and complete_rx_reset mt76: make mt76x02_vif_init return int mt76: add XDP support drivers/net/wireless/mediatek/mt76/dma.c | 58 +++- drivers/net/wireless/mediatek/mt76/mac80211.c | 18 drivers/net/wireless/mediatek/mt76/mt76.h | 12 ++- .../net/wireless/mediatek/mt76/mt76x0/pci.c | 3 + drivers/net/wireless/mediatek/mt76/mt76x02.h | 7 +- .../net/wireless/mediatek/mt76/mt76x02_mac.h | 1 + .../net/wireless/mediatek/mt76/mt76x02_mmio.c | 90 +++ .../net/wireless/mediatek/mt76/mt76x02_util.c | 17 +++- .../wireless/mediatek/mt76/mt76x2/pci_init.c | 2 + .../wireless/mediatek/mt76/mt76x2/pci_main.c | 1 + .../wireless/mediatek/mt76/mt76x2/usb_main.c | 3 +- include/net/mac80211.h| 4 + net/mac80211/driver-ops.h | 11 +++ net/mac80211/iface.c | 14 +++ net/mac80211/util.c | 12 +++ 15 files changed, 241 insertions(+), 12 deletions(-) -- 2.19.1
