Michał Kazior <kazikcz@xxxxxxxxx> writes: > 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?). 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
