On 2016-09-05 19:59, Toke Høiland-Jørgensen wrote: > 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. You're right, I missed that. > 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 That one works fine in my test. Thanks, - Felix
