Tim Shepard writes:
> Thanks for unconfusing me a couple weeks ago, and cluing me into how
> the limit on ->pending_frames is not really relevant for the data
> packets that go through the new intermediate queues.
>
> But I'm not sure if this would allow us to remove the limit on
> pending_frames
Felix Fietkau writes:
>> Well, presumably the upper layers won't try to transmit anything through
>> the old TX path if the start/stop logic is implemented properly. The
>> chanctx code already seems to call the ieee80211_{start,stop}_queue()
>> functions when changing context, so not sure what e
This switches ath9k over to using the mac80211 intermediate software
queueing mechanism for data packets. It removes the queueing inside the
driver, except for the retry queue, and instead pulls from mac80211 when
a packet is needed. The retry queue is used to store a packet that was
pulled but can
Tim Shepard writes:
>> +static struct sk_buff *
>> +ath_tid_pull(struct ath_atx_tid *tid)
>> +{
>> +struct ath_softc *sc = tid->an->sc;
>> +struct ieee80211_hw *hw = sc->hw;
>> +struct ath_tx_control txctl = {
>> +.txq = tid->txq,
>> +.sta = tid->an->sta,
>> +
Tim Shepard writes:
>>
>> You're right that it doesn't check the max. However, this is less of a
>> problem now that there is no intermediate queueing in the driver; and
>> indeed the utility of haven the qlen_* tunables is somewhat questionable
>> with the patch applied: The only thing this is
Toke,
I've been tesing your ath9k patch (using it instead of my earlier
ath9k patch) and plan to continue testing it.
Thanks for unconfusing me a couple weeks ago, and cluing me into how
the limit on ->pending_frames is not really relevant for the data
packets that go through the new intermedi
>
> You're right that it doesn't check the max. However, this is less of a
> problem now that there is no intermediate queueing in the driver; and
> indeed the utility of haven the qlen_* tunables is somewhat questionable
> with the patch applied: The only thing this is going to control is the
>
Oh cool.. I will try to understand this patch thoroughly in the next
couple of days.
My patch (both v1 and v2) have one or two bugs (depending on exactly
how you count bugs and/or my confusion) (that I know of).
At first glance my first bug appears to remain in your reworked patch:
>
> +sta
On 2016-07-04 19:46, Toke Høiland-Jørgensen wrote:
> Tim Shepard writes:
>
>> Thanks for unconfusing me a couple weeks ago, and cluing me into how
>> the limit on ->pending_frames is not really relevant for the data
>> packets that go through the new intermediate queues.
>>
>> But I'm not sure if