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