On Thu, 29 Nov 2018 at 14:00, Lorenzo Bianconi <lorenzo.bianconi@xxxxxxxxxx> 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ł
