Re: [ath9k-devel] [PATCH] ath9k: Switch to using mac80211 intermediate software queues.

[Toke Høiland-Jørgensen]

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 because even though normal data packets would not
> normally build up that many packets, there are other packet types
> which bypass the intermediate queues and are transmitted directly
> (also in most cases bypassing the ath9k internal queues in the way
> ath9k worked before we patched it to use the mac80211 intermediate
> queues).

Yes, but, well, since they're not queued they are not going to overflow
anything. The aggregation building logic stops at two queued aggregates,
so the default limit of 123 packets is never going to be hit when the
queue is moved into the mac80211 layer. So keeping the knobs around only
helps people who purposefully want to cripple their ability to do
aggregation; and it won't be doing what it promises (limiting qlen),
since that is now moved out of the driver. So IMO, removing the knobs is
the right thing to do. I have already updated my patch to do so, which
I'll send as a v2 once the other bits are resolved.

> Along similar lines, from reading the code I think your patch has
> introduced a bug (but I don't know how to demonstrate it at runtime).
>
> Looking in the body of ath_tx_start() at the result of applying your
> patch, we now see this:
>
>   [...]
>
>   /* Force queueing of all frames that belong to a virtual interface on
>* a different channel context, to ensure that they are sent on the
>* correct channel.
>*/
>   if (((avp && avp->chanctx != sc->cur_chan) ||
>sc->cur_chan->stopped) && !txctl->force_channel) {
>   if (!txctl->an)
>   txctl->an = >mcast_node;
>   queue = true;
>   skip_uapsd = true;
>   }
>
>   if (!skip_uapsd && ps_resp) {
>   ath_txq_unlock(sc, txq);
>   txq = sc->tx.uapsdq;
>   ath_txq_lock(sc, txq);
>   } else if(WARN_ON(txctl->an && queue)) 
>   ath_txq_unlock(sc, txq);
>   return -EINVAL;
>   }
>
>   [...]
>
> In the case where the first if body above is run to force queuing of
> all packets (not just normal data packets), then the else case of the
> second if statement above will surely run and its if statement will
> surely be true, so your new WARN_ON will happen.

Yup, I'm aware of that (and it's why I put in the WARN_ON instead of
just removing those code paths). Haven't seen it trigger yet, but
haven't tried very hard either. Guess you're right that it requires
vifs on different channels...

> Earlier Felix said:
>
>> Channel context based queue handling can be dealt with by
>> stopping/starting relevant queues on channel context changes.
>
> But I don't see how to handle the case here where packets get passed
> to the driver with ath_tx_start() and wind up in the scenario above.

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 else is needed. Guess
I'll go see if I can provoke an actual triggering of the bug, unless
Felix elaborates on what he means before I get around to it (poke,
Felix? :)).

-Toke
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] [PATCH] ath9k: Switch to using mac80211 intermediate software queues.

[Toke Høiland-Jørgensen]

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't be sent immediately.

The old code path in ath_tx_start that would queue packets has been
disabled and turned into a WARN_ON() and failure. Figure it can be
removed in a v2 (or kept and removed later).

Based on Tim's original patch set, but reworked quite thoroughly.

Cc: Tim Shepard 
Cc: Felix Fietkau 
Signed-off-by: Toke Høiland-Jørgensen 
---
 drivers/net/wireless/ath/ath9k/ath9k.h |   8 +-
 drivers/net/wireless/ath/ath9k/debug_sta.c |   4 +-
 drivers/net/wireless/ath/ath9k/init.c  |   1 +
 drivers/net/wireless/ath/ath9k/main.c  |   1 +
 drivers/net/wireless/ath/ath9k/xmit.c  | 254 ++---
 5 files changed, 129 insertions(+), 139 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h 
b/drivers/net/wireless/ath/ath9k/ath9k.h
index 5294595..b9cdf20 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -145,7 +145,9 @@ int ath_descdma_setup(struct ath_softc *sc, struct 
ath_descdma *dd,
 #define BAW_WITHIN(_start, _bawsz, _seqno) \
_seqno) - (_start)) & 4095) < (_bawsz))
 
-#define ATH_AN_2_TID(_an, _tidno)  (&(_an)->tid[(_tidno)])
+#define ATH_STA_2_TID(_sta, _tidno) ((struct ath_atx_tid 
*)(_sta)->txq[_tidno]->drv_priv)
+#define ATH_VIF_2_TID(_vif) ((struct ath_atx_tid *)(_vif)->txq->drv_priv)
+#define ATH_AN_2_TID(_an, _tidno) ((_an)->sta ? ATH_STA_2_TID((_an)->sta, 
_tidno) : ATH_VIF_2_TID((_an)->vif))
 
 #define IS_HT_RATE(rate)   (rate & 0x80)
 #define IS_CCK_RATE(rate)  ((rate >= 0x18) && (rate <= 0x1e))
@@ -232,7 +234,6 @@ struct ath_buf {
 
 struct ath_atx_tid {
struct list_head list;
-   struct sk_buff_head buf_q;
struct sk_buff_head retry_q;
struct ath_node *an;
struct ath_txq *txq;
@@ -247,13 +248,13 @@ struct ath_atx_tid {
s8 bar_index;
bool active;
bool clear_ps_filter;
+   bool has_queued;
 };
 
 struct ath_node {
struct ath_softc *sc;
struct ieee80211_sta *sta; /* station struct we're part of */
struct ieee80211_vif *vif; /* interface with which we're associated */
-   struct ath_atx_tid tid[IEEE80211_NUM_TIDS];
 
u16 maxampdu;
u8 mpdudensity;
@@ -585,6 +586,7 @@ void ath9k_release_buffered_frames(struct ieee80211_hw *hw,
   u16 tids, int nframes,
   enum ieee80211_frame_release_type reason,
   bool more_data);
+void ath9k_wake_tx_queue(struct ieee80211_hw *hw, struct ieee80211_txq *queue);
 
 //
 /* VIFs */
diff --git a/drivers/net/wireless/ath/ath9k/debug_sta.c 
b/drivers/net/wireless/ath/ath9k/debug_sta.c
index c2ca57a..d789798 100644
--- a/drivers/net/wireless/ath/ath9k/debug_sta.c
+++ b/drivers/net/wireless/ath/ath9k/debug_sta.c
@@ -52,8 +52,8 @@ static ssize_t read_file_node_aggr(struct file *file, char 
__user *user_buf,
 "TID", "SEQ_START", "SEQ_NEXT", "BAW_SIZE",
 "BAW_HEAD", "BAW_TAIL", "BAR_IDX", "SCHED", "PAUSED");
 
-   for (tidno = 0, tid = >tid[tidno];
-tidno < IEEE80211_NUM_TIDS; tidno++, tid++) {
+   for (tidno = 0; tidno < IEEE80211_NUM_TIDS; tidno++) {
+   tid = ATH_STA_2_TID(an->sta, tidno);
txq = tid->txq;
ath_txq_lock(sc, txq);
if (tid->active) {
diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c
index 1c226d6..1434018 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -867,6 +867,7 @@ static void ath9k_set_hw_capab(struct ath_softc *sc, struct 
ieee80211_hw *hw)
hw->max_rate_tries = 10;
hw->sta_data_size = sizeof(struct ath_node);
hw->vif_data_size = sizeof(struct ath_vif);
+   hw->txq_data_size = sizeof(struct ath_atx_tid);
hw->extra_tx_headroom = 4;
 
hw->wiphy->available_antennas_rx = BIT(ah->caps.max_rxchains) - 1;
diff --git a/drivers/net/wireless/ath/ath9k/main.c 
b/drivers/net/wireless/ath/ath9k/main.c
index 3aed43a..f584e19 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -2673,4 +2673,5 @@ struct ieee80211_ops ath9k_ops = {
.sw_scan_start  = ath9k_sw_scan_start,
.sw_scan_complete   = ath9k_sw_scan_complete,
.get_txpower= ath9k_get_txpower,
+   .wake_tx_queue  = ath9k_wake_tx_queue,
 };
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c 
b/drivers/net/wireless/ath/ath9k/xmit.c
index fe795fc..81fd480 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ 

Re: [ath9k-devel] [PATCH] ath9k: Switch to using mac80211 intermediate software queues.

[Toke Høiland-Jørgensen]

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,
>> +};
>> +struct sk_buff *skb;
>> +struct ath_frame_info *fi;
>> +int q;
>> +
>> +if (!tid->has_queued)
>> +return NULL;
>> +
>> +skb = ieee80211_tx_dequeue(hw, container_of((void*)tid, struct 
>> ieee80211_txq, drv_priv));
>> +if (!skb) {
>> +tid->has_queued = false;
>> +return NULL;
>> +}
>> +
>> +if (ath_tx_prepare(hw, skb, )) {
>> +ieee80211_free_txskb(hw, skb);
>> +return NULL;
>> +}
>> +
>> +q = skb_get_queue_mapping(skb);
>> +if (tid->txq == sc->tx.txq_map[q]) {
>> +fi = get_frame_info(skb);
>> +fi->txq = q;
>> +++tid->txq->pending_frames;
>> +}
>> +
>> +return skb;
>> + }
>> +
>> +
>
> The increment of ->pending_frames lacks a corresponding check against
> sc->tx.txq_max_pending to see if we've reached the limit.  (Which begs
> the question: what to do if it has?)
>
> I discovered this bug doing experiments by trying to turn down the
> various /sys/kernel/debug/ieee80211/phy0/ath9k/qlen_* to low numbers
> (including as low as one, and then even zero) and found it had no
> effect.

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
size of the retry queue, and possible limit the size of the retry queue.
The actual queueing is happening in the mac80211 layer, which these
tunables can't control (and which is not FQ-CoDel controlled in
mac80211-next). So it might actually be that simply removing the
tunables is the right thing to do with this patch.

Removing the limits would also probably mean getting rid of txq->stopped
and the calls to ieee80211_wake_queue() and ieee80211_stop_queue().
I suspect that is fine when using the mac80211 intermediate queues, but
I'm not sure.

Felix, care to comment? :)

> The second more mysterious bug which I'm still struggling to
> understand is why doesn't large values in these ath9k/qlen_* (or more
> accurately, given the first bug above, the failure to check these qlen
> limit values at all) allow for increased hardware queue bloat (with
> observable delay).

Because there's a second limit in play (which has always been there): in
ath_tx_sched_aggr() there is this check:

if ((aggr && txq->axq_ampdu_depth >= ATH_AGGR_MIN_QDEPTH) ||
(!aggr && txq->axq_depth >= ATH_NON_AGGR_MIN_QDEPTH)) {
__skb_queue_tail(>retry_q, bf->bf_mpdu);
*stop = true;
return false;
}

The two constants are 2 and 8 respectively. This means that, with
aggregation enabled, no more than two full aggregates will be queued up.
The size of the aggregates is dynamically computed from the current
rate: they are limited a maximum of four milliseconds of (estimated)
airtime (for the BE queue; the others have different limits).

So in a sense there's already a dynamic limit on the hardware queues.
Now, whether four milliseconds is the right maximum aggregate size might
be worth discussing. It is the maximum allowed by the standard. Dave and
I have been 

-Toke
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: Switch to using mac80211 intermediate software queues.

[Toke Høiland-Jørgensen]

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 going to control is the
>> size of the retry queue, and possible limit the size of the retry queue.
>> []
>
> The driver queues things up for the hardware to DMA and transmit.
> Something has to limit the amount of packets handed over to the
> hardware.  (We lack access to hardware documentation (g!) but it
> appears to me that the hardware has a hard limit on how many packets
> can be handed to it.)

There's a ring buffer eight entries long that the aggregates (or
packets) are put on when actually being handed to the hardware.

This is in ath_txq->txq_fifo.

>> Because there's a second limit in play (which has always been there): in
>> ath_tx_sched_aggr() there is this check:
>> 
>>  if ((aggr && txq->axq_ampdu_depth >= ATH_AGGR_MIN_QDEPTH) ||
>>  (!aggr && txq->axq_depth >= ATH_NON_AGGR_MIN_QDEPTH)) {
>>  __skb_queue_tail(>retry_q, bf->bf_mpdu);
>>  *stop = true;
>>  return false;
>>  }
>> 
>> The two constants are 2 and 8 respectively. This means that, with
>> aggregation enabled, no more than two full aggregates will be queued up.
>> The size of the aggregates is dynamically computed from the current
>> rate: they are limited a maximum of four milliseconds of (estimated)
>> airtime (for the BE queue; the others have different limits).
>> 
>> So in a sense there's already a dynamic limit on the hardware queues.
>> Now, whether four milliseconds is the right maximum aggregate size might
>> be worth discussing. It is the maximum allowed by the standard. Dave and
>> I have been 
>
> Ah that may be the clue that I lacked.  There's got to be a dependency
> on processor speed (how quickly the system and driver can get another
> packet hooked up for transmission after completions) but perhaps with
> aggregates being so large in time, with full aggregates even the
> slowest processors are fast enough to avoid starvation.
>
> If there's no aggregation, a limit of some sort is needed (probably to
> prevent malfunction of the hardware/driver, but in any case to limit
> excess latency).  And this limit will depend on processor speed (and
> will need to be autotuned at runtime).

ATH_NON_AGGR_MIN_QDEPTH is 8 -- so yeah, the limit is higher if there is
no aggregation.

These are hard-coded values, so presumably they are large enough to keep
the hardware busy on most platforms (or someone would have noticed and
changed them?). So I doubt there is much to be gained to add a mechanism
to dynamically tune them (between 0 and 2?).

The exception being in case pulling from the mac80211 queue is too slow
to keep the hardware busy at the current settings. I see no problems
with this on my hardware, but that's an x86 box. I would probably hold
off on the dynamic tuning until having proven that there's actually a
bottleneck, though... ;)

-Toke
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: Switch to using mac80211 intermediate software queues.

[Tim Shepard]

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 intermediate queues.

But I'm not sure if this would allow us to remove the limit on
pending_frames because even though normal data packets would not
normally build up that many packets, there are other packet types
which bypass the intermediate queues and are transmitted directly
(also in most cases bypassing the ath9k internal queues in the way
ath9k worked before we patched it to use the mac80211 intermediate
queues).


Along similar lines, from reading the code I think your patch has
introduced a bug (but I don't know how to demonstrate it at runtime).

Looking in the body of ath_tx_start() at the result of applying your
patch, we now see this:

[...]

/* Force queueing of all frames that belong to a virtual interface on
 * a different channel context, to ensure that they are sent on the
 * correct channel.
 */
if (((avp && avp->chanctx != sc->cur_chan) ||
 sc->cur_chan->stopped) && !txctl->force_channel) {
if (!txctl->an)
txctl->an = >mcast_node;
queue = true;
skip_uapsd = true;
}

if (!skip_uapsd && ps_resp) {
ath_txq_unlock(sc, txq);
txq = sc->tx.uapsdq;
ath_txq_lock(sc, txq);
} else if(WARN_ON(txctl->an && queue)) 
ath_txq_unlock(sc, txq);
return -EINVAL;
}

[...]


In the case where the first if body above is run to force queuing of
all packets (not just normal data packets), then the else case of the
second if statement above will surely run and its if statement will
surely be true, so your new WARN_ON will happen.

This is why I left the previous ath9k internal queueing mechanisms in
place.  I couldn't figure out how to handle the above case without
leaving the ath9k internal queueing mechanisms.

I'm not sure how to test for this though... I don't know what sort of
configuration scenario I would need to set up to generate the above
situation and trigger the warning. (Presumably, it involves multiple
vifs on different channels.)  But unless the first if statement body
is dead code that can never happen, I think you've introduced a bug
here (with a good WARN_ON to make it obvious when it happens).

Earlier Felix said:

> Channel context based queue handling can be dealt with by
> stopping/starting relevant queues on channel context changes.

But I don't see how to handle the case here where packets get passed
to the driver with ath_tx_start() and wind up in the scenario above.


-Tim Shepard
 s...@alum.mit.edu


___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: Switch to using mac80211 intermediate software queues.

[Tim Shepard]

> 
> 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
> size of the retry queue, and possible limit the size of the retry queue.
> []

The driver queues things up for the hardware to DMA and transmit.
Something has to limit the amount of packets handed over to the
hardware.  (We lack access to hardware documentation (g!) but it
appears to me that the hardware has a hard limit on how many packets
can be handed to it.)

> > The second more mysterious bug which I'm still struggling to
> > understand is why doesn't large values in these ath9k/qlen_* (or more
> > accurately, given the first bug above, the failure to check these qlen
> > limit values at all) allow for increased hardware queue bloat (with
> > observable delay).
> 
> Because there's a second limit in play (which has always been there): in
> ath_tx_sched_aggr() there is this check:
> 
>   if ((aggr && txq->axq_ampdu_depth >= ATH_AGGR_MIN_QDEPTH) ||
>   (!aggr && txq->axq_depth >= ATH_NON_AGGR_MIN_QDEPTH)) {
>   __skb_queue_tail(>retry_q, bf->bf_mpdu);
>   *stop = true;
>   return false;
>   }
> 
> The two constants are 2 and 8 respectively. This means that, with
> aggregation enabled, no more than two full aggregates will be queued up.
> The size of the aggregates is dynamically computed from the current
> rate: they are limited a maximum of four milliseconds of (estimated)
> airtime (for the BE queue; the others have different limits).
> 
> So in a sense there's already a dynamic limit on the hardware queues.
> Now, whether four milliseconds is the right maximum aggregate size might
> be worth discussing. It is the maximum allowed by the standard. Dave and
> I have been 

Ah that may be the clue that I lacked.  There's got to be a dependency
on processor speed (how quickly the system and driver can get another
packet hooked up for transmission after completions) but perhaps with
aggregates being so large in time, with full aggregates even the
slowest processors are fast enough to avoid starvation.

If there's no aggregation, a limit of some sort is needed (probably to
prevent malfunction of the hardware/driver, but in any case to limit
excess latency).  And this limit will depend on processor speed (and
will need to be autotuned at runtime).


-Tim Shepard
 s...@alum.mit.edu

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: Switch to using mac80211 intermediate software queues.

[Tim Shepard]

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:

>  
> +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,
> + };
> + struct sk_buff *skb;
> + struct ath_frame_info *fi;
> + int q;
> +
> + if (!tid->has_queued)
> + return NULL;
> +
> + skb = ieee80211_tx_dequeue(hw, container_of((void*)tid, struct 
> ieee80211_txq, drv_priv));
> + if (!skb) {
> + tid->has_queued = false;
> + return NULL;
> + }
> +
> + if (ath_tx_prepare(hw, skb, )) {
> + ieee80211_free_txskb(hw, skb);
> + return NULL;
> + }
> +
> + q = skb_get_queue_mapping(skb);
> + if (tid->txq == sc->tx.txq_map[q]) {
> + fi = get_frame_info(skb);
> + fi->txq = q;
> + ++tid->txq->pending_frames;
> + }
> +
> + return skb;
> + }
> +
> +

The increment of ->pending_frames lacks a corresponding check against
sc->tx.txq_max_pending to see if we've reached the limit.  (Which begs
the question: what to do if it has?)

I discovered this bug doing experiments by trying to turn down the
various /sys/kernel/debug/ieee80211/phy0/ath9k/qlen_* to low numbers
(including as low as one, and then even zero) and found it had no
effect.

OK, so that's one bug.


The second more mysterious bug which I'm still struggling to
understand is why doesn't large values in these ath9k/qlen_* (or more
accurately, given the first bug above, the failure to check these qlen
limit values at all) allow for increased hardware queue bloat (with
observable delay).  I suspect that is because the driver with my patch
to use the new intermediate queues is doing something silly like
failing to have more than one aggregate at a time hooked up in the
hardware transmit queue for transmission.  But I haven't figured out
what is really happening yet.  And this bug (depending on what exactly
it turns out to be) might make the low latency results some of you
have seen somewhat problematic to understand because it might be the
case that with my patch as it is (up to now) there's a flaw that leads
to low latency and gives up some throughput by simply failing to keep
the device busy transmitting packets when there are packets to send.

Fixing this bug might increase latency...  my plan all along has been
to put something in akin to autotuning like we have in bql/dql in
wired network interfaces.  Note the right amount to queue depends on
CPU performance capability in running the driver... that's why it
needs to be autotuned at run time.


But anyway, Toke, between struggling to understand this second bug and
some distractions I neglected to answer your question of almost two
weeks ago when you said:

> What's the symptom of this? As I said I haven't noticed anything, but it
> might be worth looking out for.

So now I've finally tried to answer that question.  Perhaps with your
recent work on this patch your head is loaded with context that might
be helpful in understanding this.

Tomorrow (after I get some sleep) I'm planning on taking a look at
what ath9k looks like with this patch of yours applied and see if that
makes it any easier to figure out what to do about the above bug(s) in
my original patch.

-Tim Shepard
 s...@alum.mit.edu
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: Switch to using mac80211 intermediate software queues.

[Felix Fietkau]

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 this would allow us to remove the limit on
>> pending_frames because even though normal data packets would not
>> normally build up that many packets, there are other packet types
>> which bypass the intermediate queues and are transmitted directly
>> (also in most cases bypassing the ath9k internal queues in the way
>> ath9k worked before we patched it to use the mac80211 intermediate
>> queues).
> 
> Yes, but, well, since they're not queued they are not going to overflow
> anything. The aggregation building logic stops at two queued aggregates,
> so the default limit of 123 packets is never going to be hit when the
> queue is moved into the mac80211 layer. So keeping the knobs around only
> helps people who purposefully want to cripple their ability to do
> aggregation; and it won't be doing what it promises (limiting qlen),
> since that is now moved out of the driver. So IMO, removing the knobs is
> the right thing to do. I have already updated my patch to do so, which
> I'll send as a v2 once the other bits are resolved.
I agree.

>> Earlier Felix said:
>>
>>> Channel context based queue handling can be dealt with by
>>> stopping/starting relevant queues on channel context changes.
>>
>> But I don't see how to handle the case here where packets get passed
>> to the driver with ath_tx_start() and wind up in the scenario above.
> 
> 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 else is needed. Guess
> I'll go see if I can provoke an actual triggering of the bug, unless
> Felix elaborates on what he means before I get around to it (poke,
> Felix? :)).
Then I guess the logic in ath_tx_start was a leftover from a time before
some queue related rework happened to the chanctx code.
In that case you can simply remove the chanctx related software queueing
stuff from ath_tx_start.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel