originated on the WiFi device itself (and so are not
limited by TSQ).
Signed-off-by: Toke Høiland-Jørgensen
---
net/mac80211/tx.c | 8
1 file changed, 8 insertions(+)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 25904af38839..69722504e3e1 100644
--- a/net/mac80211/tx.c
+++ b/net
Ben Greear writes:
> On 02/01/2018 02:47 PM, Johannes Berg wrote:
>> On Thu, 2018-02-01 at 23:40 +0100, Johannes Berg wrote:
>>>
>>> The code does a plain rcu_dereference(), no locking other than
>>> rcu_read_lock() involved.
>>>
>>> On second thought though, I'm not convinced that your modificat
eported-by: Ben Greear
Signed-off-by: Toke Høiland-Jørgensen
---
drivers/net/wireless/ath/ath9k/xmit.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c
b/drivers/net/wireless/ath/ath9k/xmit.c
index 396bf05c6bf6..d8b041f48ca8 100644
--- a/drivers/ne
Sebastian Gottschall writes:
> Am 31.01.2018 um 12:50 schrieb Toke Høiland-Jørgensen:
>> Sebastian Gottschall writes:
>>
>>> Am 30.01.2018 um 19:55 schrieb Toke Høiland-Jørgensen:
>>>> Ben Greear writes:
>>>>
>>>>>> I&#x
Sebastian Gottschall writes:
> Am 30.01.2018 um 19:55 schrieb Toke Høiland-Jørgensen:
>> Ben Greear writes:
>>
>>>> I'm actually working on reworking that whole scheduler logic, and move
>>>> some of it into mac80211. Could you test this (WiP) pat
Ben Greear writes:
>> I'm actually working on reworking that whole scheduler logic, and move
>> some of it into mac80211. Could you test this (WiP) patch and see if
>> that has the same problem?
>
> It had some serious conflicts in ath10k, due to my local changes, so
> I did not actually test thi
on my setup.
I'm actually working on reworking that whole scheduler logic, and move
some of it into mac80211. Could you test this (WiP) patch and see if
that has the same problem?
-Toke
mac80211: Add TXQ scheduling API
From: Toke Høiland-Jørgensen
This adds an API to mac80211 to handle sc
Ben Greear writes:
> On 01/29/2018 01:47 PM, Toke Høiland-Jørgensen wrote:
>> Ben Greear writes:
>>
>>> On 01/27/2018 05:11 AM, Toke Høiland-Jørgensen wrote:
>>>> Ben Greear writes:
>>>>
>>>>> I'm doing a test with 200 virt
Ben Greear writes:
> On 01/27/2018 05:11 AM, Toke Høiland-Jørgensen wrote:
>> Ben Greear writes:
>>
>>> I'm doing a test with 200 virtual stations on each of 6 ath9k radios.
>>>
>>> When I configure stations for DHCP, I see cases where stations o
Ben Greear writes:
> On 01/27/2018 05:29 AM, Toke Høiland-Jørgensen wrote:
>> gree...@candelatech.com writes:
>>
>>> From: Ben Greear
>>>
>>> The PAUSED field was never printed per tid. Replace that
>>> with has_queued, which might help
gree...@candelatech.com writes:
> From: Ben Greear
>
> The PAUSED field was never printed per tid. Replace that
> with has_queued, which might help someone track down strange
> bugs related to aqm.
>
> And, make tx-queue debug info show peer BSSID as well as vdev
> MAC to aid debugging with mult
Ben Greear writes:
> I'm doing a test with 200 virtual stations on each of 6 ath9k radios.
>
> When I configure stations for DHCP, I see cases where stations on a particular
> radio will not transmit anything sometimes. I see no 'XMIT' logs that show
> indication of
> frames being received in t
Felix Fietkau writes:
> On 2017-12-14 13:15, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau writes:
>>
>>> On 2017-10-31 12:27, Toke Høiland-Jørgensen wrote:
>>>> This adds an API to mac80211 to handle scheduling of TXQs and changes the
>>>&g
Felix Fietkau writes:
> On 2017-10-31 12:27, Toke Høiland-Jørgensen wrote:
>> This adds an API to mac80211 to handle scheduling of TXQs and changes the
>> interface between driver and mac80211 for TXQ handling as follows:
>>
>> - The wake_tx_queue callback interface
Kalle Valo writes:
> Toke Høiland-Jørgensen writes:
>
>>> Sorry for the inconvenience, I hadn't realized mt76 went in now.
>>
>> Yeah, hadn't expected these streams to cross either.
>
> I did ask[1] if everyone are ok that I apply mt76 and I didn&#
Johannes Berg writes:
> Hi Stephen,
>
> Thanks!
>
> Felix made me aware of this yesterday evening and said he's going to
> work out the required changes to mt76.
>
> Kalle and I will make sure to submit the trees to Dave one by one so he
> doesn't have to deal with it :)
>
> Unfortunately, this m
Johannes Berg writes:
> On Fri, 2017-12-01 at 16:54 +0100, Toke Høiland-Jørgensen wrote:
>
>> But since we'll have to do that for ath9k anyway it
>> becomes more a question of whether it's something that should be
>> supported in mac80211 or if it should be
Johannes Berg writes:
> On Fri, 2017-12-01 at 16:29 +0100, Toke Høiland-Jørgensen wrote:
>>
>> Yeah, figures. Well, maybe we'll just have to support an asynchronous
>> callback into mac80211 to register airtime usage. Will probably have to
>> add some asynchro
Kalle Valo writes:
>>> tx_duration is aggregate time duration of 4 PPDU sent to STA.
>>> FW sends these values for retry packets also.
>>
>> Great, that sounds like just what we need.
>
> Except mapping to the iee80211_tx_status() might be difficult. I'm not
> sure how HTT_T2H_MSG_TYPE_PKTLOG eve
ako...@codeaurora.org writes:
> On 2017-11-30 22:08, Kalle Valo wrote:
>> Toke Høiland-Jørgensen writes:
>>
>>>>> +struct ath10k_10_2_peer_tx_stats {
>>>>> + u8 ratecode[PEER_STATS_FOR_NO_OF_PPDUS];
>>>>> + u8 success_pk
>> +struct ath10k_10_2_peer_tx_stats {
>> +u8 ratecode[PEER_STATS_FOR_NO_OF_PPDUS];
>> +u8 success_pkts[PEER_STATS_FOR_NO_OF_PPDUS];
>> +__le16 success_bytes[PEER_STATS_FOR_NO_OF_PPDUS];
>> +u8 retry_pkts[PEER_STATS_FOR_NO_OF_PPDUS];
>> +__le16 retry_bytes[PEER_STATS_FOR_NO_O
Felix Fietkau writes:
> On 2017-11-10 01:48, Toke Høiland-Jørgensen wrote:
>> Commit 4ca1807815aa6801aaced7fdefa9edacc2521767 disables the use of the
>> mac80211 TXQs for some devices because of a theoretical throughput
>> regression. The original regression report[1] wa
Rajkumar Manoharan writes:
> Agree.. Even I am not fan of that patch in ath10k. IIRC Michal pushed
> this change as temp one and planned to revert it once it is fixed in
> stack or in driver.
>
> I thought Eric change in fq_codel is meant only for fatty udp flows.
> Forgive my ignorance.
It is,
. Since then, we have not seen
the TXQ-related regression, so it should be safe to re-enable TXQs.
[1] http://lists.infradead.org/pipermail/ath10k/2016-April/007266.html
Signed-off-by: Toke Høiland-Jørgensen
---
This has been in LEDE trunk for a couple of months now with good
results.
Changes since v1
able TXQs.
>>
>> Signed-off-by: Toke Høiland-Jørgensen
>> ---
>> This has been in LEDE trunk for a couple of months now with good results.
>>
> Toke,
>
> Good to know that the performance drop is not seen with the chips that does
> not
> have push-pull
Commit 4ca1807815aa6801aaced7fdefa9edacc2521767 disables the use of the
mac80211 TXQs for some devices because of a theoretical throughput
regression. We have not seen this regression for a while now, so it
should be safe to re-enable TXQs.
Signed-off-by: Toke Høiland-Jørgensen
---
This has been
supposed to call it to re-schedule the TXQ after it is
finished pulling packets from it (unless the queue emptied).
The ath9k and ath10k drivers are changed to use the new API.
Signed-off-by: Toke Høiland-Jørgensen
---
Changes since v2:
- Fix build error of first patch in the series reported by the
This removes the in-driver airtime fairness scheduling from ath9k and
switches the driver to use the API introduced in mac80211 in the
previous commit.
Signed-off-by: Toke Høiland-Jørgensen
---
drivers/net/wireless/ath/ath9k/ath9k.h | 7 +---
drivers/net/wireless/ath/ath9k/debug.h | 8
scheduling.
Signed-off-by: Toke Høiland-Jørgensen
---
include/net/mac80211.h | 24
net/mac80211/debugfs.c | 1 +
net/mac80211/debugfs_sta.c | 29 +
net/mac80211/ieee80211_i.h | 9 +++--
net/mac80211/main.c| 3 ++-
net/mac80211
This removes the in-driver airtime fairness scheduling from ath9k and
switches the driver to use the API introduced in mac80211 in the
previous commit.
Signed-off-by: Toke Høiland-Jørgensen
---
Changes since v1:
- Split out ath9k changes into separate patch
drivers/net/wireless/ath/ath9k
scheduling.
Signed-off-by: Toke Høiland-Jørgensen
---
Changes since v1:
- Split ath9k changes into separate patch
- Rename RX status variable to 'airtime', add documentation
- Add documentation on usage to the IEEE80211_HW_AIRTIME_ACCOUNTING hw
accounting flag
- Remove HW flag check on RX
supposed to call it to re-schedule the TXQ after it is
finished pulling packets from it (unless the queue emptied).
The ath9k and ath10k drivers are changed to use the new API.
Signed-off-by: Toke Høiland-Jørgensen
---
Changes since v1:
- Also remove artxq->list member from ath10k
- Don
Johannes Berg writes:
> On Tue, 2017-10-17 at 09:34 +0200, Toke Høiland-Jørgensen wrote:
>
>> Yeah, I did that initially. The reason I ended up squashing them is
>> that
>> this patch moved the per-station 'airtime' debugfs-entry that was
>> previously c
Johannes Berg writes:
>> Only ath9k currently sets the AIRTIME_ACCOUNTING flag.
>
> I think you should actually make that a separate patch.
>
> In the previous patch that's not possible or it breaks things, but
> this patch just adds a new feature that drivers _may_ use, they don't
> have to sinc
scheduling, which is then removed.
Only ath9k currently sets the AIRTIME_ACCOUNTING flag.
Signed-off-by: Toke Høiland-Jørgensen
---
Changes since the RFC:
- Don't try to calculate airtime usage in mac80211; instead, add a field to
struct ieee80211_rx_status for the driver to fill in.
- Fold
supposed to call it to re-schedule the TXQ after it is finished pulling
packets from it (unless the queue emptied).
The ath9k and ath10k drivers are changed to use the new API.
Signed-off-by: Toke Høiland-Jørgensen
---
Changes since the RFC:
- Don't call wake_tx_queue() if the TXQ was al
violations.
Signed-off-by: Toke Høiland-Jørgensen
---
include/net/fq_impl.h | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/include/net/fq_impl.h b/include/net/fq_impl.h
index 4e6131cd3f43..ac1a2317941e 100644
--- a/include/net/fq_impl.h
+++ b/include/net/fq_impl.h
Johannes Berg writes:
> On Wed, 2017-10-11 at 16:06 +0200, Toke Høiland-Jørgensen wrote:
>
>> > Hmm, not sure. We really want this to be scheduled pretty much
>> > immediately because the other side will be waiting for the frames,
>> > and
>> > if we don
Johannes Berg writes:
>> Well I was trying to do The Right Thing(tm), obviously ;)
>
> :-)
>
>> The driver_buffered field comes from the previous behaviour of ath9k:
>> It would basically set the station_buffered flag if there was
>> something in the retry queue at the time it goes to sleep. And
Johannes Berg writes:
> On Tue, 2017-10-10 at 19:51 +0200, Toke Høiland-Jørgensen wrote:
>
>> > > +struct list_head active_txqs;
>> > > +spinlock_t active_txq_lock;
>> >
>> > Is there much point in having a separate lock? We proba
Johannes Berg writes:
>> Yeah, ath9k certainly gets that as part of the RX information from
>> the chip.
>
> Yeah, though there are more complex cases, e.g. with hardware A-MSDU
> deaggregation like in ath10k.
Here be dragons; noted :)
>> Well, some of the tests I did while porting ath9k to the
Johannes Berg writes:
>> In particular, I'm not sure what the right thing to do in regards to
>> PS wakeup is...
>
> Can you explain what you were _trying_ to do?
>
> I don't like calling this "driver_buffered" because that's already a
> term for frames that are buffered in the driver ... :-)
We
Johannes Berg writes:
> On Tue, 2017-10-10 at 16:02 +0200, Toke Høiland-Jørgensen wrote:
>
>> +++ b/net/mac80211/agg-tx.c
>> @@ -226,9 +226,11 @@ ieee80211_agg_start_txq(struct sta_info *sta,
>> int tid, bool enable)
>> clear_bit(IEE
This removes TXQ scheduling from ath9k and changes it to use the mac80211 TXQ
scheduling API introduced in the previous patch.
Signed-off-by: Toke Høiland-Jørgensen
---
drivers/net/wireless/ath/ath9k/ath9k.h | 7 +-
drivers/net/wireless/ath/ath9k/channel.c | 2 -
drivers/net/wireless/ath
supposed to call it to re-schedule the TXQ after it is finished pulling
packets from it (unless the queue emptied).
- A drv_buffered flag is added to struct ieee80211_txq which the driver can set
to request mac80211 to re-schedule the TXQ at PS wakeup.
Signed-off-by: Toke Høiland-Jørgensen
---
This
This removes TXQ scheduling from ath10k and changes it to use the mac80211 TXQ
scheduling API introduced in the previous patch.
Signed-off-by: Toke Høiland-Jørgensen
---
drivers/net/wireless/ath/ath10k/core.c | 2 --
drivers/net/wireless/ath/ath10k/core.h | 3 ---
drivers/net/wireless/ath
Johannes Berg writes:
> Hi,
>
>> Right, but most of these are constant values that are straight
>> forward to add as long as you know how the frame was received, no?
>> Maybe not as a general function in mac80211, but the driver should be
>> able to perform a reasonable computation in the absence
Johannes Berg writes:
> On Mon, 2017-10-09 at 11:42 +0200, Toke Høiland-Jørgensen wrote:
>
>> Well, the padding and spacing between frames is at most 11 bytes (4-
>> byte delimiter, 4-byte FCS and 3-byte padding), which is ~0.7% of a
>> full-sized frame. I'm not too
Johannes Berg writes:
> On Sat, 2017-10-07 at 13:22 +0200, Toke Høiland-Jørgensen wrote:
>
>> Guess you are right that it will be difficult to get a completely
>> accurate number. But as David Lang notes, as long as we are off by
>> the same amount for all stations, t
Johannes Berg writes:
> On Fri, 2017-10-06 at 16:29 +0200, Toke Høiland-Jørgensen wrote:
>> Johannes Berg writes:
>>
>> Well, calculating the duration from the rate and size is what ath9k
>> is currently doing, and that has all the information available to do
&
Johannes Berg writes:
> On Fri, 2017-10-06 at 13:52 +0200, Toke Høiland-Jørgensen wrote:
>> This adds accounting of each station's airtime usage to mac80211. On
>> the RX side, airtime is calculated from the packet length and
>> duration.
>
> I think you should pr
The actual calculation of RX airtime
- Updates of the drivers to check for the ERR_PTR and set tx_time
Signed-off-by: Toke Høiland-Jørgensen
---
net/mac80211/ieee80211_i.h | 3 +++
net/mac80211/rx.c | 30 ++
net/mac80211/sta_info.c| 1 +
net/mac80211/sta_info
ace that's being removed.
>
> Signed-off-by: Johannes Berg
Acked-by: Toke Høiland-Jørgensen
Johannes Berg writes:
> From: Johannes Berg
>
> When removing an AP VLAN interface, mac80211 currently purges
> the entire TXQ for the AP interface. Fix this by using the FQ
> API introduced in the previous patch to filter frames.
>
> Signed-off-by: Johannes Berg
A
Johannes Berg writes:
>> The obvious alternative is to do a token-based airtime scheduler,
>> where the airtime used by one station is immediately divided out to
>> all active stations. But that requires walking over all active
>> stations on every TX completion, and there's a lot of housekeeping
Johannes Berg writes:
> On Thu, 2017-10-05 at 18:28 +0200, Toke Høiland-Jørgensen wrote:
>
>> I'm been thinking about how to move the airtime fairness scheduler
>> out of ath9k and into mac80211 (so more drivers can take advantage of
>> it). This will require som
Johannes Berg writes:
> Part 2 - where can we go from here
>
>
> Of course - as mentioned in the subject - my goal is to just convert
> over to TXQs entirely in mac80211. That would get rid of a LOT of
> special case code, like queueing for aggregation setup, powersave
> buffering (both unicast a
Johannes Berg writes:
> From: Johannes Berg
>
> Add to the FQ API a way to filter a given tin, in order to
> remove frames that fulfil certain criteria according to a
> filter function.
>
> This will be used by mac80211 to remove frames belonging to
> an AP VLAN interface that's being removed.
>
Johannes Berg writes:
> +static void fq_tin_filter(struct fq *fq,
> + struct fq_tin *tin,
> + fq_skb_filter_t filter_func,
> + void *filter_data,
> + fq_skb_free_t free_func)
> +{
> + struct list_head *hea
Johannes Berg writes:
> On Tue, 2017-09-05 at 11:49 +0200, Toke Høiland-Jørgensen wrote:
>>
>> Ah, so the station is attached to the VLAN interface, not the parent
>> interface?
>
> Doesn't actually matter, but if the VLAN goes where the station belongs
> th
Johannes Berg writes:
> On Tue, 2017-09-05 at 11:02 +0200, Toke Høiland-Jørgensen wrote:
>>
>> > I'm not sure. However, I think it's less bad than one might guess
>> > since it really should only affect multicast frames, right? All
>> > unicas
Johannes Berg writes:
> On Mon, 2017-09-04 at 16:23 +0200, Toke Høiland-Jørgensen wrote:
>>
>> Hmm, not apart from agreeing with you that it would be better to not
>> drop everything when removing a VLAN. Not sure how often this
>> happens, though (and hence how bi
Johannes Berg writes:
> On Mon, 2017-08-21 at 15:32 +0200, Toke Høiland-Jørgensen wrote:
>>
>> > + struct ieee80211_vif *vif;
>> > struct ieee80211_key_conf *hw_key;
>> > u32 flags;
>
Johannes Berg writes:
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index b2b5419467cc..263cb30d77c8 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -919,21 +919,10 @@ struct ieee80211_tx_info {
> unsigned long jiffies;
>
Johannes Berg writes:
> On Thu, 2017-04-06 at 11:38 +0200, Toke Høiland-Jørgensen wrote:
>> CoDel can be too aggressive if a station sends at a very low rate,
>> leading reduced throughput. This gets worse the more stations are
>> present, as each station gets more bursty
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->
, 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
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
"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
Felix Fietkau writes:
> On 2017-02-12 17:36, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau writes:
>>
>>> On 2017-02-12 17:28, Kalle Valo wrote:
>>>> Felix Fietkau writes:
>>>>
>>>>> On 2017-02-12 16
Felix Fietkau writes:
> On 2017-02-12 17:28, Kalle Valo wrote:
>> Felix Fietkau writes:
>>
>>> On 2017-02-12 16:22, Toke Høiland-Jørgensen wrote:
>>>> Felix Fietkau writes:
>>>>
>>>>> ath_tx_count_airtime is doing a
rg
> Fixes: 63fefa050477 ("ath9k: Introduce airtime fairness scheduling between
> stations")
> Signed-off-by: Felix Fietkau
Not sure if there's anything for stable to do with this; don't think the
airtime fairness code has gone into a release yet? Otherwise:
Acked-by: Toke Høiland-Jørgensen
-Toke
Klaus Kinski writes:
> The captures I used to create the statistics are here:
> https://drive.google.com/open?id=0ByFGz3ZH6JcYMGp0a05lYzBPNzA
>
> An obvious difference is, that Madwifi sends 5 packets in a row
> without waiting for an ACK whereas ath9k/mac80211 always seems to wait
> for an ACK.
Klaus Kinski writes:
> Hello all,
>
> this is a blast from the past, but something that still bothers me.
> I have two systems with Atheros/QCA cards:
>
> System A:
> OS and driver: Linux 3.18.36 with last Madwifi/sample code from trunk
>
> WLAN card: AR5413 (Senao EMP-8602 PLUS-S)
>
> System
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
-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
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
"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
-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
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
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
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
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
Acked-by: Toke Høiland-Jørgensen
-Toke
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
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
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-
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:
>>>>>
>>>
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:
>
>>>>> 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
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
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:
>> 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:
> 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:
> 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
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
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
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
-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
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
301 - 400 of 491 matches
Mail list logo
