Jason Andryuk writes:
> On Thu, Sep 1, 2016 at 12:03 PM, Toke Høiland-Jørgensen wrote:
>> @@ -1481,33 +1506,57 @@ struct sk_buff *ieee80211_tx_dequeue(struct
>> ieee80211_hw *hw,
>> {
>> struct ieee80211_local *local = hw_to_local(hw);
>> struct txq_info *txqi = container_of(tx
On Thu, Sep 1, 2016 at 12:03 PM, Toke Høiland-Jørgensen wrote:
> @@ -1481,33 +1506,57 @@ struct sk_buff *ieee80211_tx_dequeue(struct
> ieee80211_hw *hw,
> {
> struct ieee80211_local *local = hw_to_local(hw);
> struct txq_info *txqi = container_of(txq, struct txq_info, txq);
> -
> To avoid having to deal with fragmentation on dequeue, the split is
> set to be after the fragmentation handler. This means that some
> reordering of TX handlers is necessary, and some handlers had to be
> made aware of fragmentation due to this reordering.
Come to think of it, that's actually
On Thu, 2016-09-01 at 20:30 +0200, Toke Høiland-Jørgensen wrote:
> > seq=1,frag=0
> > seq=2,frag=0
> > seq=2,frag=1
> > seq=2,frag=1
> >
> > if reordering happened?
>
> (assuming the last line was supposed to read 'seq=1,frag=1')
I did actually mean seq=2,frag=1, since the seqno assignment happ
Johannes Berg writes:
>> To avoid having to deal with fragmentation on dequeue, the split is
>> set to be after the fragmentation handler. This means that some
>> reordering of TX handlers is necessary, and some handlers had to be
>> made aware of fragmentation due to this reordering.
>
> Come to
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
