> 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 >
