"Tobin C. Harding" writes:
> Except one: do you know off the top of your head of a canonical
> implementation of a softmac wi-fi driver.
I'll suggest taking a look at the ath9k driver :)
-Toke
throughput, so the same adjustment can be made for
cards that implement rate control in firmware. Drivers that don't use
this will just get the default parameters.
Signed-off-by: Toke Høiland-Jørgensen
---
Changes since v1:
- Get rid of the hysteresis (in practice we don't go above and be
, so the same adjustment can be made for
cards that implement rate control in firmware. Drivers that don't use
this will just get the default parameters.
Signed-off-by: Toke Høiland-Jørgensen
---
Changes since v2:
- Messed up the rebase and squash in v2; this one actually compiles...
includ
Eric Dumazet writes:
> On Thu, 2017-04-06 at 11:38 +0200, Toke Høiland-Jørgensen wrote:
>
>> +
>> +if (thr && thr < STA_SLOW_THRESHOLD * sta->local->num_sta) {
>> +sta->cparams.target = MS2TIME(50);
>> +sta->
sdnlabs Janakaraj writes:
> Hello Toke,
> Thanks for sharing this information.
>
> I took a look at Flent yesterday and planning to test it by the
> weekend due to something things I have to catch up with.
Awesome! Let me know if you run into any problems :)
-Toke
Arend van Spriel writes:
> On 2/19/2018 6:02 PM, Toke Høiland-Jørgensen wrote:
>> This series adds TXQ parameters and statistics that were previously only
>> available through debugfs to the nl80211 userspace interface and the
>> cfg80211 kernel interface. Patches for iw to
Arend van Spriel writes:
>>> So can we expect some manual in which is described what parameter
>>> should be tweaked based on the retrieved statistics.
>>
>> Heh, not sure I'll promise a whole manual, but I am happy to write a
>> blog post (or wiki page if that's better) explaining what these val
MHz, center1: 5825 MHz
txpower 24.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol
tx-bytestx-packets
0 0 72 0 0 0 0 7380
72
Signed-off-by: Toke Høiland-Jørgensen
On 24 March 2018 00:00:39 GMT, Ben Greear wrote:
>On 02/02/2018 02:36 AM, Toke Høiland-Jørgensen wrote:
>> When ath9k was switched over to use the mac80211 intermediate queues,
>> node cleanup now drains the mac80211 queues. However, this call path
>is
>> not protected
Bernhard Gabler writes:
> Dear all,
>
> would it be possible to re-write the log message from
> "regdomain ... dynamically updated by country IE"
> in a less ambiguous way, e.g. to:
> "regdomain ... dynamically updated by country-IE"
> "regdomain ... dynamically updated by country inf
Johannes Berg writes:
> On Wed, 2018-04-18 at 16:55 +0200, Toke Høiland-Jørgensen wrote:
>>
>> Heh, that is a good point, I think. The patch below should fix it; but I
>> worry that the log lines become quite long, then? Maybe better to use
>> "country-IE&q
Reported-by: Bernhard Gabler
Signed-off-by: Toke Høiland-Jørgensen
---
net/wireless/reg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 16c7e4ef5820..ecfee5f06c76 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@
Toke Høiland-Jørgensen writes:
> This series adds TXQ parameters and statistics that were previously only
> available through debugfs to the nl80211 userspace interface and the
> cfg80211 kernel interface. Patches for iw to print the statistics and
> change the settings are includ
Johannes Berg writes:
> On Thu, 2018-04-19 at 11:20 +0200, Toke Høiland-Jørgensen wrote:
>> Toke Høiland-Jørgensen writes:
>>
>> > This series adds TXQ parameters and statistics that were previously only
>> > available through debugfs to the nl80211 userspac
Johannes Berg writes:
> On Fri, 2018-04-20 at 00:32 +0200, Bernhard Gabler wrote:
>
>> looking at the patch, I see more occurences of the outdated "IE" in a
>> constant name and function name:
>>
>> case NL80211_REGDOM_SET_BY_COUNTRY_IE:
>> or
>> reg_process_hint_country_ie()
slightly more complex.
Signed-off-by: Toke Høiland-Jørgensen
---
Changes since v3:
- Fix sequence number assignment in the fast path.
- Code cleanup.
include/net/mac80211.h | 2 +
net/mac80211/tx.c | 269 ++---
net/mac80211/wpa.c | 18
Johannes Berg writes:
>> +static int invoke_tx_handlers(struct ieee80211_tx_data *tx)
>> +{
>> +return invoke_tx_handlers_early(tx) ||
>> invoke_tx_handlers_late(tx);
>> +}
>
> Ugh, please, no, don't be tricky where it's not necessary. Now every
> person reading this has to first look up the
Johannes Berg writes:
>> > > +static int invoke_tx_handlers(struct ieee80211_tx_data *tx)
>> > > +{
>> > > +return invoke_tx_handlers_early(tx) ||
>> > > invoke_tx_handlers_late(tx);
>> > > +}
>> >
>> > Ugh, please, no, don't be tricky where it's not necessary. Now
>> > every
>> > person
Johannes Berg writes:
>> > They have three possible values ... :)
>>
>> Ah, no, not the handlers themselves. Meant the invoke_tx_handlers()
>> function (or all three of them after my patch; hence the plural). To
>> avoid the "0 means true" confusion you alluded to :)
>>
>
> Ah. Actually, even I
Johannes Berg writes:
>> Yeah, was going to do that anyway. But since I'm touching the code
>> anyway, this might be an opportunity to avoid constructs like this:
>>
>> if (!invoke_tx_handlers(tx))
>> /* continue sending the packet */
>>
>> Most other succeed/fail functions seem to be of type
slightly more complex.
Signed-off-by: Toke Høiland-Jørgensen
---
Changes since v4:
- Keep fragnum assignment in fragmentation handler and fix endianness
issues in seqno handler.
- Assume xmit_fast_finish can't fail in dequeue handler (and warn if
fast_tx handle disappears).
- Move TKIP MI
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
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);
>> str
mplex.
Signed-off-by: Toke Høiland-Jørgensen
---
Changes since v5:
- Move the fragmentation handler to *after* TXQ dequeue. Fragments are
kept in the TXQ for subsequent dequeues. This change also means that
the changes to make some of the handlers fragmentation aware are no
longer necessary.
- O
pard
Cc: Felix Fietkau
Signed-off-by: Toke Høiland-Jørgensen
---
Changes since v4:
- Fix regression where PS response frames (which go through the old TX
path) would not get assigned a seqno because the tid variable was not
assigned correctly. Many thanks to Felix for debugging this and coming
Toke Høiland-Jørgensen writes:
> 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, thi
mplex.
Signed-off-by: Toke Høiland-Jørgensen
---
Changes since v6:
- Invoking the rate control handler can cause packets to be generated
(for establishing a BA session). This can cause a deadlock because
dequeue can happen while sta->lock is held. So this version moves
the rate control
Felix Fietkau writes:
> On 2016-09-05 13:30, Toke Høiland-Jørgensen wrote:
>> 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 en
mplex.
Signed-off-by: Toke Høiland-Jørgensen
---
Changes since v6:
- Invoking the rate control handler can cause packets to be generated
(for establishing a BA session). This can cause a deadlock because
dequeue can happen while sta->lock is held. So this version moves
the rate control
mplex.
Signed-off-by: Toke Høiland-Jørgensen
---
Changes since v8:
- Don't rely on the fast_tx pointer on TXQ dequeue; it can go away while
the packet was queued, and we don't actually need it, since we can get
the key configuration and offset from the packet info.
include/net/mac80
Toke Høiland-Jørgensen writes:
> 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, thi
ble to return
an expected rate (and so will be considered 'fast').
Cc: Michal Kazior
Cc: Felix Fietkau
Cc: Dave Taht
Signed-off-by: Toke Høiland-Jørgensen
---
net/mac80211/sta_info.c | 37 +
net/mac80211/sta_info.h | 13 +
net/mac8021
Felix Fietkau writes:
> On 2016-09-08 21:59, Toke Høiland-Jørgensen wrote:
>> CoDel can be too aggressive if a station sends at a very low rate. This
>> gets worse the more stations are present, as each station gets more
>> bursty the longer the round-robin scheduling b
er be too lenient than
too aggressive. A better algorithm can then be added later.
Cc: Michal Kazior
Cc: Felix Fietkau
Signed-off-by: Toke Høiland-Jørgensen
---
include/net/mac80211.h | 17 +
net/mac80211/rate.c | 2 ++
net/mac80211/sta_info.c
Jim Gettys writes:
>> On Sat, Sep 10, 2016 at 3:33 PM, Toke Høiland-Jørgensen wrote:
>>
>> CoDel can be too aggressive if a station sends at a very low rate,
>> leading to starvation. This gets worse the more stations are present, as
>> each station gets mo
Felix Fietkau writes:
> On 2016-09-12 12:07, Johannes Berg wrote:
>> On Mon, 2016-09-12 at 12:05 +0200, Felix Fietkau wrote:
>>> On 2016-09-12 12:03, Johannes Berg wrote:
>>> >
>>> >
>>> > >
>>> > > Hm, I guess I didn't think of that. I guess this potential issue
>>> > > will
>>> > > go away o
Johannes Berg writes:
>> +static int invoke_tx_handlers_late(struct ieee80211_tx_data *tx);
>> +static bool ieee80211_xmit_fast_finish(struct ieee80211_sub_if_data *sdata,
>> + struct sta_info *sta, u8 pn_offs,
>> + struct ieee80
global per phy, one per netdev and one per
station, in the appropriate directories. The files are all called aqm,
and are only created if the driver supports the wake_tx_queue op (rather
than emitting an error on open as previously).
Signed-off-by: Toke Høiland-Jørgensen
---
Change
The TXQ path restructure requires ieee80211_tx_dequeue() to call TX
handlers and parts of the xmit_fast path. Move the function to later in
tx.c in preparation for this.
Signed-off-by: Toke Høiland-Jørgensen
---
net/mac80211/tx.c | 90 +++
1
code slightly more complex.
Signed-off-by: Toke Høiland-Jørgensen
---
include/net/mac80211.h | 2 +
net/mac80211/ieee80211_i.h | 8 ++
net/mac80211/rx.c | 4 +-
net/mac80211/sta_info.c| 10 +-
net/mac80211/tx.c | 287 +
net/mac
er the TXQ has anything queued to also look at the 'frags' queue.
- Don't change the order of the select_key handler with respect to the
other handlers.
- Rebase on current mac80211-next tree.
Toke Høiland-Jørgensen (2):
mac80211: Move ieee802111_tx_dequeue() to later in tx.c
-by: Toke Høiland-Jørgensen
---
include/net/fq.h | 3 +++
include/net/fq_impl.h | 7 ++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/net/fq.h b/include/net/fq.h
index 268b490..6d8521a 100644
--- a/include/net/fq.h
+++ b/include/net/fq.h
@@ -72,9 +72,12 @@ struct
Add memory limit, usage and overlimit counter to per-PHY 'aqm' debugfs
file.
Signed-off-by: Toke Høiland-Jørgensen
---
net/mac80211/debugfs.c | 8
1 file changed, 8 insertions(+)
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index 8ca62b6..f56e2f4 100644
Small devices can run out of memory from queueing too many packets. If
VHT is not supported by the PHY, having more than 4 MBytes of total
queue in the TXQ intermediate queues is not needed, and so we can safely
limit the memory usage in these cases and avoid OOM.
Signed-off-by: Toke Høiland
nd lower 4 Mbytes of
total queue (2048 packets, 64 max-size aggregates) is plenty, and so it
is safe to simply limit the queue size. And (b) that VHT-capable devices
are usually installed in systems equipped with more system memory.
Toke Høiland-Jørgensen (3):
fq.h: Port memory limit mech
Johannes Berg writes:
> Hi Toke,
>
> Sorry for the delay reviewing this.
>
> I think I still have a few comments/questions.
No worries. And not terribly surprised ;)
>> +static inline bool txq_has_queue(struct ieee80211_txq *txq)
>> +{
>> +struct txq_info *txqi = to_txq_info(txq);
>> +r
Johannes Berg writes:
> On Fri, 2016-09-23 at 21:59 +0200, Toke Høiland-Jørgensen wrote:
>> Small devices can run out of memory from queueing too many packets.
>> If VHT is not supported by the PHY, having more than 4 MBytes of
>> total queue in the TXQ intermediate queues
Johannes Berg writes:
>> Not sure if you want a v10, or if you're satisfied with the above
>> comments and will just fix up the nits on merging?
>>
>
> I'll fix it up. Thanks!
Cool, thanks :)
-Toke
Johannes Berg writes:
> Applied, with the nits fixed as discussed.
Awesome, thanks!
> Come to think of it, if somebody is bored ;-) perhaps a hwsim option
> to use TXQs (should be optional I guess) would be nice so we can
> exercise this code with the wpa_supplicant hwsim tests. That would
> ha
Johannes Berg writes:
>> > I kinda see the logic here - we really don't need to queue as much
>> > if we can't possibly transmit it out quickly - but it seems to me
>> > we should also throw in some kind of limit that's relative to the
>> > amount of memory you have on the system?
>>
>> Yes, ide
Kalle Valo writes:
> Toke Høiland-Jørgensen 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
>>>>> wait for 4.10? IMHO applyin
Kalle Valo writes:
> Toke Høiland-Jørgensen writes:
>
>> Kalle Valo writes:
>>
>>> Toke Høiland-Jørgensen writes:
>>>
>>> I understand your point, but I don't want to rush this to 4.9 and then
>>> start getting lots of bug reports and
Kalle Valo writes:
> Toke Høiland-Jørgensen writes:
>
>> Kalle Valo writes:
>>
>>> Toke Høiland-Jørgensen writes:
>>>
>>>> Kalle Valo writes:
>>>>
>>>>> Toke Høiland-Jørgensen writes:
>>>>>
>>>
on condition
> in ieee80211_xmit_fast_finish, which skipped seqno alloc if intermediate
> tx queues are being used.
>
> Drop the now obsolete condition.
>
> Fixes: bb42f2d13ffc ("mac80211: Move reorder-sensitive TX handlers to after
> TXQ dequeue")
> Signed-
Dan Carpenter writes:
> Hello Toke Høiland-Jørgensen,
>
> This is a semi-automatic email about new static checker warnings.
>
> The patch bb42f2d13ffc: "mac80211: Move reorder-sensitive TX handlers
> to after TXQ dequeue" from Sep 22, 2016, leads to the following
the session has
> been terminated and also ensures that aggregation starts right after the
> session has been established
Makes sense. Suppose there's no reason why the session couldn't be
started/ended while packets were queued.
Acked-by: Toke Høiland-Jørgensen
Acked-by: Toke Høiland-Jørgensen
-Toke
Felix Fietkau writes:
> A-MSDU aggregation alters the QoS header after a frame has been
> enqueued, so it needs to be ready before enqueue and not overwritten
> again afterwards
Acked-by: Toke Høiland-Jørgensen
Tim Shepard writes:
>> While at it, could you also add to the commit log some info how awesome this
>> patch is from user's point of view and how it helps. For example, before and
>> and after numbers and other results.
>
> That varies wildly, depending on many details of the scenario
> (includin
c on iface:11.2 pkts1.9 pkts
This patch set: 13.9 pkts1.9 pkts
This patch is 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
---
Changes since v5:
- Reb
Kalle Valo 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 instead pulls from mac80211 when
-by: Toke Høiland-Jørgensen
---
drivers/net/wireless/ath/ath9k/ath9k.h | 28 -
drivers/net/wireless/ath/ath9k/channel.c | 26 -
drivers/net/wireless/ath/ath9k/debug.c | 3 +
drivers/net/wireless/ath/ath9k/debug.h | 13 +++
drivers/net/wireless/ath/ath9k/debug_sta.c | 54
"Valo, Kalle" writes:
> (The make-wifi-fast list is annoying as it always spams me when it's on
> CC, so dropped it.)
>
> Toke Høiland-Jørgensen writes:
>
>> This reworks the ath9k driver to schedule transmissions to connected
>> stations in a way that
Felix Fietkau writes:
> On 2016-11-27 16:58, Toke Høiland-Jørgensen wrote:
>> "Valo, Kalle" writes:
>>
>>> (The make-wifi-fast list is annoying as it always spams me when it's on
>>> CC, so dropped it.)
>>>
>>> Toke Høiland-Jør
-by: Toke Høiland-Jørgensen
---
Changes since v2:
- Just call spin_*lock_bh() instead of introducing ath_acq_*lock()
functions.
drivers/net/wireless/ath/ath9k/ath9k.h | 25 +++-
drivers/net/wireless/ath/ath9k/channel.c | 14 ++-
drivers/net/wireless/ath/ath9k/debug.c | 3
These are one-line functions that just call spin_lock/unlock_bh(); turn
them into static inlines to avoid the function call overhead.
Signed-off-by: Toke Høiland-Jørgensen
---
drivers/net/wireless/ath/ath9k/ath9k.h | 11 +--
drivers/net/wireless/ath/ath9k/xmit.c | 12
2
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();
>> +
>> + astats = &an->airt
Michal Kazior writes:
> This patchset disables qdiscs for drivers
> using software queuing and performs fq_codel-like
> dequeuing on txqs.
Hi Michal
Is this version in a git repo somewhere I can pull from? :)
-Toke
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
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
---
drivers/net/wireless/ath/ath9k/ath9
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 interface.
Software queuing used
Michal Kazior (1):
mac80211: skip 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
-off-by: Toke Høiland-Jørgensen
---
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/ath9k/main.c | 6
diate queue.
Signed-off-by: Tim Shepard
Reworked to not require the global variable renaming in ath9k.
Signed-off-by: Toke Høiland-Jørgensen
---
drivers/net/wireless/ath/ath9k/ath9k.h | 16 +++-
drivers/net/wireless/ath/ath9k/debug_sta.c | 7 +-
drivers/net/wireless/ath/ath9k/i
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
---
drivers/net/wireless/ath/ath9k/recv.c | 51
Tim Shepard writes:
>> Reworked to not require the global variable renaming in ath9k.
>>
>> Signed-off-by: Toke Høiland-Jørgensen
>
> Huh. I wonder why you did that? Is it really better to call the
> ieee80211_txq a swq and call the ath9k hardware queue a txq? I
&
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 benchmark, if you know the p
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 items for ensuring
>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
t
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 reference a field in a stru
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 hardware. There seem
Toke Høiland-Jørgensen 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
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 the middle one, we can
>> 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
>
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 comparing the rs_stamp betw
Michal Kazior writes:
> On 10 June 2016 at 11:08, Toke Høiland-Jørgensen wrote:
>> 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
>>&
Toke Høiland-Jørgensen 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) and HW alwa
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
---
drivers/net/wireless/
diate queue.
Signed-off-by: Tim Shepard
Reworked to not require the global variable renaming in ath9k.
Signed-off-by: Toke Høiland-Jørgensen
---
drivers/net/wireless/ath/ath9k/ath9k.h | 16 +++-
drivers/net/wireless/ath/ath9k/debug_sta.c | 7 +-
drivers/net/wireless/ath/ath9k/i
The default is enabling both TX and 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 | 3
Felix Fietkau 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 software queues, and implem
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 more understandable
>
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
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
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
pard
Cc: Felix Fietkau
Signed-off-by: Toke Høiland-Jørgensen
---
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 from struct txctl (since we just
removed the
Felix Fietkau 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 retry queue, and instea
Felix Fietkau writes:
> On 2016-07-06 20:52, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau writes:
>>
>>> On 2016-07-06 18:16, Toke Høiland-Jørgensen wrote:
>>>> This switches ath9k over to using the mac80211 intermediate software
>>>> que
1 - 100 of 491 matches
Mail list logo
