On Wed, 2016-01-27 at 15:26 +0100, Michal Kazior wrote:
> This will allow drivers to make more educated
> decisions whether to defer transmission or not.
>
> Relying on wake_tx_queue() call count implicitly
> was not possible because it could be called
> without queued frame count actually changin
On Wed, 2016-01-27 at 15:33 +0100, Michal Kazior wrote:
> On 27 January 2016 at 15:26, Johannes Berg > wrote:
> > On Wed, 2016-01-27 at 15:26 +0100, Michal Kazior wrote:
> > >
> > > @@ -1294,6 +1298,8 @@ struct sk_buff *ieee80211_tx_dequeue(struct
> > > ieee80211_hw *hw,
> > > if (!skb)
> >
On 27 January 2016 at 15:26, Johannes Berg wrote:
> On Wed, 2016-01-27 at 15:26 +0100, Michal Kazior wrote:
>>
>> @@ -1294,6 +1298,8 @@ struct sk_buff *ieee80211_tx_dequeue(struct
>> ieee80211_hw *hw,
>> if (!skb)
>> goto out;
>>
>> + txqi->byte_cnt -= skb->len;
>> +
>>
On Wed, 2016-01-27 at 15:26 +0100, Michal Kazior wrote:
>
> @@ -1294,6 +1298,8 @@ struct sk_buff *ieee80211_tx_dequeue(struct
> ieee80211_hw *hw,
> if (!skb)
> goto out;
>
> + txqi->byte_cnt -= skb->len;
> +
> atomic_dec(&sdata->txqs_len[ac]);
>
This *looks* a bit
This will allow drivers to make more educated
decisions whether to defer transmission or not.
Relying on wake_tx_queue() call count implicitly
was not possible because it could be called
without queued frame count actually changing on
software tx aggregation start/stop code paths.
It was also not
