Felix Fietkau <nbd@xxxxxxxx> writes: > On 2016-09-05 13:30, Toke Høiland-Jørgensen wrote: >> The TXQ intermediate queues can cause packet reordering when more than >> one flow is active to a single station. Since some of the wifi-specific >> packet handling (notably sequence number and encryption handling) is >> sensitive to re-ordering, things break if they are applied before the >> TXQ. >> >> This splits up the TX handlers and fast_xmit logic into two parts: An >> early part and a late part. The former is applied before TXQ enqueue, >> and the latter after dequeue. The non-TXQ path just applies both parts >> at once. >> >> Because fragments shouldn't be split up or reordered, the fragmentation >> handler is run after dequeue. Any fragments are then kept in the TXQ and >> on subsequent dequeues they take precedence over dequeueing from the FQ >> structure. >> >> This approach avoids having to scatter special cases for when TXQ is >> enabled, at the cost of making the fast_xmit and TX handler code >> slightly more complex. > In my test, this one completely breaks ath9k with the txq patch. > One or two packets go through, then tx stalls completely. I assume you are testing on LEDE? It requires a change to work with the patch in the LEDE tree that puts hdrlen into ieee80211_tx_data. Did you fix that? Otherwise multicast (and possibly other things) will break badly. I have a version that should work with LEDE here: https://kau.toke.dk/git/lede/tree/package/kernel/mac80211/patches/346-mac80211-move-reorder-sensitive-tx-handlers-to-after-TXQ-dequeue.patch -Toke
