Toke Høiland-Jørgensen <toke@xxxxxxx> writes: > 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. > > Signed-off-by: Toke Høiland-Jørgensen <toke@xxxxxxx> > --- > Changes since v5: > - Move the fragmentation handler to *after* TXQ dequeue. Fragments are > kept in the TXQ for subsequent dequeues. This change also means that > the changes to make some of the handlers fragmentation aware are no > longer necessary. > - One of the TX stats updates in the fast path was done before the > enqueue step; move that to xmit_fast_finish(). > - Move the rate selection handler to after dequeue, so it's run closer > to the time where the packet is actually transmitted. Found one other thing that needs fixing shortly after posting this, but figure that I'm probably not done anyway, so will leave it for the next round. :) -Toke
