Kalle Valo <kv...@codeaurora.org> writes:
> Toke Høiland-Jørgensen <t...@toke.dk> writes:
>
>> Kalle Valo <kv...@codeaurora.org> writes:
>>
>>> Toke Høiland-Jørgensen <t...@toke.dk> writes:
>>>
>>>> Kalle Valo <kv...@code
Kalle Valo <kv...@codeaurora.org> writes:
> Toke Høiland-Jørgensen <t...@toke.dk> writes:
>
>> Kalle Valo <kv...@codeaurora.org> writes:
>>
>>> Toke Høiland-Jørgensen <t...@toke.dk> writes:
>>>
>>> I understand your point,
Kalle Valo <kv...@codeaurora.org> writes:
> Toke Høiland-Jørgensen <t...@toke.dk> writes:
>
>>>>> This is great work but due to the regressions I'm not sure if this
>>>>> will be ready for 4.9. To get more testing time I wonder if we should
&g
Kalle Valo <kv...@codeaurora.org> writes:
> Toke Høiland-Jørgensen <t...@toke.dk> writes:
>
>> Kalle Valo <kv...@codeaurora.org> writes:
>>
>>> Toke Høiland-Jørgensen <t...@toke.dk> writes:
>>>
>>>> This switches ath9k
Kalle Valo <kv...@codeaurora.org> writes:
> Toke Høiland-Jørgensen <t...@toke.dk> writes:
>
>> This switches ath9k over to using the mac80211 intermediate software
>> queueing mechanism for data packets. It removes the queueing inside the
>> driver, except fo
Felix Fietkau <n...@nbd.name> writes:
> On 2016-07-08 18:28, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau <n...@nbd.name> writes:
>>
>>> On 2016-07-08 17:53, Toke Høiland-Jørgensen wrote:
>>>> Kalle Valo <kv...@qca.qualcomm.co
Sebastian Gottschall writes:
> for me it crashes on wds sta on 3.18 kernels.
Bugger :/
> need to solder a serial to get more logs
That would be helpful :)
-Toke
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
t;s...@alum.mit.edu>
Cc: Felix Fietkau <n...@nbd.name>
Signed-off-by: Toke Høiland-Jørgensen <t...@toke.dk>
---
Changes since v3 (most due to Felix; thanks!):
- Correctly notify mac80211 when there are packets in the retry queue
on powersave start/stop.
- Get rid of ath_tx_aggr_
Tim Shepard writes:
>> The old code path in ath_tx_start that would queue packets has been
>> removed completely,
>
> It seems to me that this breaks the ath9k driver when non-data packets
> which mac80211 will not queue on the new intermediate queues, see
> ieee80211_drv_tx(
Felix Fietkau <n...@nbd.name> writes:
> On 2016-07-08 17:53, Toke Høiland-Jørgensen wrote:
>> Kalle Valo <kv...@qca.qualcomm.com> writes:
>>
>>> Toke Høiland-Jørgensen wrote:
>>>> This switches ath9k over to using the mac80211 intermediate s
t;s...@alum.mit.edu>
Cc: Felix Fietkau <n...@nbd.name>
Signed-off-by: Toke Høiland-Jørgensen <t...@toke.dk>
---
Changes since v2:
- Add safeguard against looping infinitely in
ath_tx_get_tid_subframe().
drivers/net/wireless/ath/ath9k/ath9k.h | 12 +-
drivers/net/wireless/ath/ath9k
Felix Fietkau <n...@nbd.name> writes:
> On 2016-07-06 20:52, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau <n...@nbd.name> writes:
>>
>>> On 2016-07-06 18:16, Toke Høiland-Jørgensen wrote:
>>>> This switches ath9k over to using the mac80211 interm
Kalle Valo <kv...@qca.qualcomm.com> writes:
> Toke Høiland-Jørgensen wrote:
>> 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
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
t;s...@alum.mit.edu>
Cc: Felix Fietkau <n...@nbd.name>
Signed-off-by: Toke Høiland-Jørgensen <t...@toke.dk>
---
Changes since v1:
- Remove the old intermediate queueing logic completely instead of
just disabling it.
- Remove the qlen debug tunables.
- Remove the force_channel parameter
Felix Fietkau <n...@nbd.name> writes:
> On 2016-07-06 18:16, Toke Høiland-Jørgensen wrote:
>> 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 ret
t;s...@alum.mit.edu>
Cc: Felix Fietkau <n...@nbd.name>
Signed-off-by: Toke Høiland-Jørgensen <t...@toke.dk>
---
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/wireles
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 =
Felix Fietkau <n...@nbd.name> writes:
> On 2016-06-17 11:09, Toke Høiland-Jørgensen wrote:
>> This patch leaves the code for ath9k's internal per-node per-tid
>> queues in place and just modifies the driver to also pull from
>> the new mac80211 intermediate soft
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
Tim Shepard writes:
> Hmm... if the renaming is going to go in mainline, I feel pretty
> strongly it should go in *before* a patch to switch over to use the
> intermediate queues. The whole point of the renaming was to make the
> code that uses the intermediate queues much
Adrian Chadd writes:
> Right. In the case of RX'ing an A-MPDU, we only get told about the
> A-MPDU boundaries (isaggr/lastaggr or something in the RX descriptor)
> but nothing telling us how long the original RX'ed PPDU is.
>
> So if we get say 16 frames and we are missing
RX.
- Squashed the whole thing into one patch and rebased to mac80211-next.
Toke Høiland-Jørgensen (2):
ath9k: use mac80211 intermediate software queues
ath9k: Add a per-station airtime deficit scheduler
drivers/net/wireless/ath/ath9k/ath9k.h | 34 +++-
drivers/net/wireless/ath/at
makes decisions.
Uses the ts->duration + retry-chain information to account for time
spent transmitting to a station. The RX airtime is measured as the
duration from first to last frame in an aggregate, using the rs_tstamp
fields.
Signed-off-by: Toke Høiland-Jørgensen <t...@toke.dk>
---
dr
Toke Høiland-Jørgensen <t...@toke.dk> writes:
>> No idea. If that's possible, then track last MPDU within PPDU, so you
>> can at least fallback to _something_ when you detect a new first
>> (A-)MPDU?
>>
>> Or maybe it's impossible (i.e. not worth worrying
Michal Kazior writes:
> For A-MPDU all MPDU rx status (except last one) should share the same
> timestamp. Last one has a different one so all you need is to
> distinguish first and last MPDU. Non A-MPDU obviously are special case
> (status bits are pricky).
Right. So
queue.
Signed-off-by: Tim Shepard <s...@alum.mit.edu>
Reworked to not require the global variable renaming in ath9k.
Signed-off-by: Toke Høiland-Jørgensen <t...@toke.dk>
---
drivers/net/wireless/ath/ath9k/ath9k.h | 16 +++-
drivers/net/wireless/ath/ath9k/debug_sta.c | 7 +-
Michal Kazior <michal.kaz...@tieto.com> writes:
> On 10 June 2016 at 11:08, Toke Høiland-Jørgensen <t...@toke.dk> wrote:
>> Michal Kazior <michal.kaz...@tieto.com> writes:
>>
>>> For A-MPDU all MPDU rx status (except last one) should share the same
>
Toke Høiland-Jørgensen <t...@toke.dk> writes:
>> [snip]
>>
>> I also found one of my notes in my version of this - how can we
>> estimate the duration of an A-MPDU, when we only get hardware
>> de-encapsulated frames?
>
> Well in my case I'm sideste
>> I initially thought that using the timestamp put into the frame by the
>> hardware could be a way to get timing. But there's only a timestamp of
>> the first symbol in rs_tstamp, and getting a time to compare it with is
>> difficult; by the time the frame is handled in the rx tasklet, way too
Tim Shepard writes:
> OK, makes sense. But you left it called txq in mac80211. So someone
> reading the mac80211 code and ath9k at the same time (to understand
> the whole stack) winds up with txq meaning different things, including
> in places in ath9k where it has to
Adrian Chadd writes:
> [snip]
>
> I also found one of my notes in my version of this - how can we
> estimate the duration of an A-MPDU, when we only get hardware
> de-encapsulated frames?
Well in my case I'm sidestepping this by getting the TX duration from a
register in the
Luca Muscariello writes:
> I don't fully understand your plots but it would be useful to report
> the physical rate of the stations.
Yes, well, there's not really one rate to report for each station, since
Minstrel jumps about a bit and tries different ones.
> As a
Julian Calaby writes:
> As this patch is passing through your hands, you need to add your
> Signed-off-by too.
Ah, right, sorry; didn't know that. Will add it the next time around.
Thanks for the pointer! :)
-Toke
___
Adrian Chadd writes:
> I've been working on something similar in freebsd, so cool to see this
> happening here!
Cool. Do you have code available somewhere?
> The only thing missing atm is STBC and LDPC. My RX airtime code looks
> basically like this one too; but I have TODO
From: Michal Kazior
Qdiscs are designed with no regard to 802.11
aggregation requirements and hand out
packet-by-packet with no guarantee they are
destined to the same tid. This does more bad than
good no matter how fairly a given qdisc may behave
on an ethernet
-off-by: Toke Høiland-Jørgensen <t...@toke.dk>
---
drivers/net/wireless/ath/ath9k/ath9k.h | 8 ++-
drivers/net/wireless/ath/ath9k/channel.c | 12 ++--
drivers/net/wireless/ath/ath9k/debug.h | 8 +++
drivers/net/wireless/ath/ath9k/debug_sta.c | 12
drivers/net/wireless/ath
queue.
Signed-off-by: Tim Shepard <s...@alum.mit.edu>
Reworked to not require the global variable renaming in ath9k.
Signed-off-by: Toke Høiland-Jørgensen <t...@toke.dk>
---
drivers/net/wireless/ath/ath9k/ath9k.h | 16 +++-
drivers/net/wireless/ath/ath9k/debug_sta.c | 7 +-
This adds RX airtime to the airtime deficit used in the scheduler. This
is not a definite win, but I have only done very limited testing where
it has been included. Feel free to skip this patch when testing.
Signed-off-by: Toke Høiland-Jørgensen <t...@toke.dk>
---
drivers/net/wireless/ath
netdev queue control with software queuing
Toke Høiland-Jørgensen (4):
ath9k: use mac80211 intermediate software queues
ath9k: Add airstame stats to per-station debugfs
ath9k: Add a per-station airtime deficit scheduler
ath9k: Count RX airtime in airtime deficit.
drivers/net/wireless/ath
Uses the ts->duration + retry-chain information to account for time
spent transmitting to a station. Calculates the RX airtime from the rate
and packet length. Hopefully these figures are not too inaccurate.
Signed-off-by: Toke Høiland-Jørgensen <t...@toke.dk>
---
drivers/net/wireless/
David Lang writes:
> There are two parts to this process
>
> 1. the tactical (do you send the pending packet immediately, or do you
> delay it to see if you can save airtime with aggregation)
A colleague of mine looked into this some time ago as part of his PhD
thesis. This was
This is my attempt to add per-station airtime usage accounting to ath9k.
For now I just export it to a new debugfs entry, but my plan is to use
it to make (station) scheduling decisions. However, before attempting
that I would like some feedback from someone more familiar with the
ath9k than me as
Michal Kazior writes:
>> +void ath_debug_tx_airtime(struct ath_softc *sc,
>> + struct ath_node *an,
>> + struct ath_tx_status *ts)
>> +{
>> + struct ath_airtime_stats *astats;
>> +
>> + rcu_read_lock();
>> +
>>
44 matches
Mail list logo