Ryan Adolf writes:
> The patch is attached.
> There's only one modified line in it: correcting the typo of timstamp
> --> timestamp.
You'll probably need to send this as a properly formatted patch. Pretty
simple to do:
- Make you change (you already did that)
- Run 'git add event.c; git commit
Johannes Berg writes:
> On Sun, 2019-10-06 at 19:40 +0200, Toke Høiland-Jørgensen wrote:
>
>> > That's a good point. I haven't thought about real simultaneous dual
>> > band chipset and such chipset do exists now. Is RSDB support coming to
>> > mac
Kan Yan writes:
> Hi Johannes,
>
> Thanks for help review this patch. I will fix all style errors.
>
>> > +ieee80211_txq_airtime_check(struct ieee80211_hw *hw, struct ieee80211_txq
>> > *txq);
>> Why is it necessary to call this, vs. just returning NULL when an SKB is
>> requested?
> This funct
Kan Yan writes:
> In order for the Fq_CoDel integrated in mac80211 layer operates
> effectively to control excessive queueing latency, the CoDel algorithm
> requires an accurate measure of how long the packets stays in the
> queue, aka sojourn time. The sojourn time measured at mac80211 layer
> d
org/lkml/nycvar.yfh.7.76.1909111238470@cbobk.fhfr.pm/
>
> Reported-by: Jiri Kosina
> Reported-by: Aaron Hill
> Reported-by: Lukas Redlinger
> Reported-by: Oleksii Shevchuk
> Signed-off-by: Johannes Berg
Reviewed-by: Toke Høiland-Jørgensen
Johannes Berg writes:
> On Tue, 2019-10-01 at 12:53 +0200, Toke Høiland-Jørgensen wrote:
>>
>> > - spin_unlock_bh(&fq->lock);
>> > + spin_unlock(&fq->lock);
>> >drv_wake_tx_queue(local, txq
Johannes Berg writes:
> From: Johannes Berg
>
> Drivers typically expect this, as it's the case for almost all cases
> where this is called (i.e. from the TX path). Also, the code in mac80211
> itself (if the driver calls ieee80211_tx_dequeue()) expects this as it
> uses this_cpu_ptr() without a
Johannes Berg writes:
> On Tue, 2019-10-01 at 11:08 +0200, Toke Høiland-Jørgensen wrote:
>>
>> Awesome! Any idea for how to make it work on big-endian systems? I got a
>> splat from the kbuild robot that triggered the BUILD_BUG_ON when
>> building for m68k. I
Johannes Berg writes:
> On Thu, 2019-09-19 at 14:22 +0200, Toke Høiland-Jørgensen wrote:
>
> Given a ULL constant:
>
>> +/* constants for calculating reciprocals to avoid division in fast path */
>> +#define IEEE80211_RECIPROCAL_DIVISOR 0x1
Johannes Berg writes:
> Hi,
>
> Sorry for the long time to review here ...
>
> On Thu, 2019-09-19 at 14:22 +0200, Toke Høiland-Jørgensen wrote:
>> From: Toke Høiland-Jørgensen
>>
>> To implement airtime queue limiting, we need to keep a running account of
>
Kan Yan writes:
>> I guess the risk is lower when with a 24ms per-iface limit; but with
>> enough stations I guess it could still happen, no? So we should probably
>> handle this case...
> Each txq (per sta, per tid) is allowed to release at least the lower
> AQL limit amount of packet (default 4
Felix Fietkau writes:
> On 2019-09-29 20:42, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau writes:
>>
>>> Rate success probability usually fluctuates a lot under normal conditions.
>>> With a simple EWMA, noise and fluctuation can be reduced by increasing the
Kan Yan writes:
>> No, ath10k would continue to do what it was always doing. Drivers that
>> can report after-the-fact airtime usage per-frame (like ath9k) will
>> continue to do that. In both of those cases, the airtime estimate is
>> only used to throttle the queue, not to schedule for fairness
Felix Fietkau writes:
> Rate success probability usually fluctuates a lot under normal conditions.
> With a simple EWMA, noise and fluctuation can be reduced by increasing the
> window length, but that comes at the cost of introducing lag on sudden
> changes.
>
> This change replaces the EWMA imp
Felix Fietkau writes:
> On 2019-09-27 11:07, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau writes:
>>
>>> On 2019-09-27 10:37, Toke Høiland-Jørgensen wrote:
>>>> Felix Fietkau writes:
>>>>
>>>>> On 2019-09-27 09
Felix Fietkau writes:
> On 2019-09-27 10:37, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau writes:
>>
>>> On 2019-09-27 09:45, Toke Høiland-Jørgensen wrote:
>>>> Felix Fietkau writes:
>>>>
>>>>> Estimate by calculating dura
Felix Fietkau writes:
> On 2019-09-27 10:35, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau writes:
>>> + switch (status->encoding) {
>>> + case RX_ENC_LEGACY:
>>> + if (WARN_ON_ONCE(status->band > NL80211_BAND_5GHZ))
>>> +
Felix Fietkau writes:
> On 2019-09-27 09:45, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau writes:
>>
>>> Estimate by calculating duration for EWMA packet size + estimated A-MPDU
>>> length on tx status events
>>
>> Would it make sense to m
Felix Fietkau writes:
> Report total rx airtime for valid stations as BSS rx time in survey
>
> mt7615 is left out for now, it will be supported later by reading
> hardware counters instead of calculating airtime in software
>
> Signed-off-by: Felix Fietkau
> ---
> drivers/net/wireless/mediatek
Felix Fietkau writes:
> It is supported by all hardware drivers now
>
> Signed-off-by: Felix Fietkau
Very happy to see this! Emphatically:
Acked-by: Toke Høiland-Jørgensen
Felix Fietkau writes:
> Estimate by calculating duration for EWMA packet size + estimated A-MPDU
> length on tx status events
Would it make sense to move some of this code into mac80211? If we're
going to do airtime estimation for queue limiting it may make sense to
use this instead of the simpl
Kan Yan writes:
>> No, but on tx_completion we could do something like this:
>> airtime = CB(skb)->tx_time ?: CB(skb)->tx_time_est;
>> ieee80211_report_airtime(sta, airtime);
>> That way, if the driver sets the tx_time field to something the firmware
>> reports, we'll use that, and otherwise we'd
Felix Fietkau writes:
> On 2019-09-26 15:17, Toke Høiland-Jørgensen wrote:
>> Oh, right. Didn't know that could happen (I assumed those would be
>> flushed out or something). But if we're going to go with Kan's
>> suggestion of having per-station accounting a
Felix Fietkau writes:
> On 2019-09-19 14:22, Toke Høiland-Jørgensen wrote:
>> From: Toke Høiland-Jørgensen
>>
>> Some devices have deep buffers in firmware and/or hardware which prevents
>> the FQ structure in mac80211 from effectively limiting bufferbloat on the
&g
Kan Yan writes:
>> Yes, please do! AFAICT, the main difference is that your version keeps
>> the airtime calculation itself in the driver, while mine passes up the
>> rate and lets mac80211 do the calculation of airtime. Other than that,
>> the differences are minor, no?
>> I'm not actually sure
Kan Yan writes:
>> > Do you mean we will use airtime reported by FW to calculate
>>
>> > local->airtime_queued in case we have FW reporting airtime?
>> No, the opposite; if the firmware can't report airtime, we can use the
>> estimated values to feed into report_airtime() for the fairness
>> calc
Yibo Zhao writes:
> On 2019-09-25 16:11, Toke Høiland-Jørgensen wrote:
>> Yibo Zhao writes:
>>
>>> So if it is going to work together with virtual time based mechanism
>>> in
>>> the future, the Tx criteria will be met both of below conditions,
&g
Yibo Zhao writes:
> So if it is going to work together with virtual time based mechanism in
> the future, the Tx criteria will be met both of below conditions,
> 1. Lower than g_vt
> 2. Lower than IEEE80211_AIRTIME_QUEUE_LIMIT
> Are we going to maintain two kinds of airtime that
Kan Yan writes:
> Hi Toke,
>
> There is an updated version of AQL in the chromiumos tree implemented
> in the mac80211 driver, instead of in the ath10k driver as the
> original version:
> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1703105/7
> https://chromium-revie
Lorenzo Bianconi writes:
>> Lorenzo Bianconi writes:
>>
>> >> From: Toke Høiland-Jørgensen
>> >>
>> >> Some devices have deep buffers in firmware and/or hardware which prevents
>> >> the FQ structure in mac80211 from effectively lim
Lorenzo Bianconi writes:
>> From: Toke Høiland-Jørgensen
>>
>> Some devices have deep buffers in firmware and/or hardware which prevents
>> the FQ structure in mac80211 from effectively limiting bufferbloat on the
>> link. For Ethernet devices we have BQL to lim
John Yates writes:
> On Thu, Sep 19, 2019 at 2:18 PM Dave Taht wrote:
>>
>> For the record, this was the google report on their implementation in 3.18.
>>
>> http://flent-newark.bufferbloat.net/~d/Airtime%20based%20queue%20limit%20for%20FQ_CoDel%20in%20wireless%20interface.pdf
>
> From skimming
Peter Oh writes:
> On 9/19/19 10:46 AM, Ben Greear wrote:
>> On 9/19/19 10:44 AM, Peter Oh wrote:
>>> On 9/19/19 5:22 AM, Toke Høiland-Jørgensen wrote:
>>>> From: Toke Høiland-Jørgensen
>>>>
>>>> This patch ports that idea over to mac80
Toke Høiland-Jørgensen writes:
> This series is a first attempt at porting the Airtime Queue Limits concept
> from
> the out-of-tree ath10k implementation[0] to mac80211. I limited the scope of
> this RFC to ath10k, but it should be straight forward to enable other drivers
> (th
From: Toke Høiland-Jørgensen
To implement airtime queue limiting, we need to keep a running account of
the estimated airtime of all skbs queued into the device. Do to this
correctly, we need to store the airtime estimate into the skb so we can
decrease the outstanding balance when the skb is
From: Toke Høiland-Jørgensen
Some devices have deep buffers in firmware and/or hardware which prevents
the FQ structure in mac80211 from effectively limiting bufferbloat on the
link. For Ethernet devices we have BQL to limit the lower-level queues, but
this cannot be applied to mac80211 because
git repo here:
https://git.kernel.org/pub/scm/linux/kernel/git/toke/linux.git/log/?h=mac80211-aql-01
[0]
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/588190/13/drivers/net/wireless-4.2/ath/ath10k/mac.c#3845
---
Toke Høiland-Jørgensen (4):
mac80211: Rearrange
From: Toke Høiland-Jørgensen
To implement airtime queue limits, we need an estimate of the transmission
rate a station is currently transmitting at. The ath10k driver already
keeps this internally, so add an API function to pass this up to mac80211.
We also keep a pre-calculated 64-bit
From: Toke Høiland-Jørgensen
Use the newly added API to pass the last_tx_bitrate up to mac80211. The
multiplication is because ath10k keeps it internally as units of 100kbps,
whereas for mac80211 we just use kbps as the variable unit.
Signed-off-by: Toke Høiland-Jørgensen
---
drivers/net
Lukas Redlinger writes:
> Hello,
>
> on Arch Linux 5.2.11 with wpa_supplicant 2.8 / 2.9 our systems
> increasingly show this issue:
>
> [72770.969617] BUG: using smp_processor_id() in preemptible []
> code: wpa_supplicant/16207
> [72770.969638] caller is ieee80211_xmit_fast_finish+0x5a/0x
Sid Hayn writes:
> I'm pretty interested in hearing this too.
Me too! :)
-Toke
Toke Høiland-Jørgensen writes:
> syzbot found a crash in dev_map_hash_update_elem(), when replacing an
> element with a new one. Jesper correctly identified the cause of the crash
> as a race condition between the initial lookup in the map (which is done
> before taking the lo
Lorenzo Bianconi writes:
> Enable Smart Carrier Sense algorithm by default in order to improve
> performances in a noisy environment
What does that do (the algorithm, that is)? :)
-Toke
Vasanthakumar Thiagarajan writes:
> On 2019-08-21 15:38, Toke Høiland-Jørgensen wrote:
>> Vasanthakumar Thiagarajan writes:
>>
>>> On 2019-08-20 22:21, Toke Høiland-Jørgensen wrote:
>>>> [... snip ... ]
>>>>
>>>>>
Wen Gong writes:
>> -Original Message-
>> From: Toke Høiland-Jørgensen
>> Sent: Thursday, August 22, 2019 8:12 PM
>> To: Wen Gong ; Wen Gong
>> ; ath...@lists.infradead.org
>> Cc: linux-wireless@vger.kernel.org
>> Subject: [EXT] RE: [PATCH 4/7]
Vasanthakumar Thiagarajan writes:
> On 2019-08-20 22:21, Toke Høiland-Jørgensen wrote:
>> [... snip ... ]
>>
>>> +static const struct ieee80211_ops ath11k_ops = {
>>> + .tx = ath11k_mac_op_tx,
>>
>> No wake_tx_que
Denis Kenzior writes:
> Hi Dan,
>
> On 8/20/19 12:53 PM, Dan Williams wrote:
>> On Tue, 2019-08-20 at 10:40 -0500, Denis Kenzior wrote:
>>> Hi Johannes,
>>>
Stop.
Your tone, and in particular the constant snide comments and
attacks on
me are, quite frankly, getting extrem
[... snip ... ]
> +static const struct ieee80211_ops ath11k_ops = {
> + .tx = ath11k_mac_op_tx,
No wake_tx_queue? :(
-Toke
Jeff Johnson writes:
> On 2019-08-15 11:57, James Prestwood wrote:
>> - Adds a new NL80211_ATTR for including a "random mac" to
>>CMD_CONNECT. This MAC is passed down the stack and gets set to
>>the net_device's address.
>
> My initial reaction is that I'd avoid using the term "random".
Johannes Berg writes:
> On Fri, 2019-07-26 at 19:36 +0530, Karthikeyan Periyasamy wrote:
>> > > Don't allow using a zero MAC address as the station
>> > > MAC address. so validated the MAC address using
>> > > is_valid_ether_addr.
>> >
>> > Theoretically, all zeroes might have been a valid addre
Yibo Zhao writes:
> On 2019-04-21 05:15, Toke Høiland-Jørgensen wrote:
>> Yibo Zhao writes:
>>
>>> On 2019-04-11 19:24, Toke Høiland-Jørgensen wrote:
>>>> Yibo Zhao writes:
>>>>
>>>>> On 2019-04-10 18:40, Toke Høiland-Jørgensen
Yibo Zhao writes:
> On 2019-04-11 19:24, Toke Høiland-Jørgensen wrote:
>> Yibo Zhao writes:
>>
>>> On 2019-04-10 18:40, Toke Høiland-Jørgensen wrote:
>>>> Yibo Zhao writes:
>>>>
>>>>> On 2019-04-10 04:41, Toke Høiland-Jørgensen
Johannes Berg writes:
> On Tue, 2019-04-16 at 10:33 +0100, Toke Høiland-Jørgensen wrote:
>>
>> > It is true because we have an entire buffering layer in mac80211 (in
>> > this case at least) and never push back to the stack.
>>
>> I'm wondering if w
Johannes Berg writes:
> On Tue, 2019-04-16 at 16:36 +0800, Herbert Xu wrote:
>> On Tue, Apr 16, 2019 at 10:04:24AM +0200, Arend Van Spriel wrote:
>> >
>> > I was just writing up an email clarifying my question. But let me summarize
>> > this email thread. The patch from Felix adds this flag in m
Yibo Zhao writes:
> On 2019-04-10 18:40, Toke Høiland-Jørgensen wrote:
>> Yibo Zhao writes:
>>
>>> On 2019-04-10 04:41, Toke Høiland-Jørgensen wrote:
>>>> Yibo Zhao writes:
>>>>
>>>>> On 2019-04-04 16:31, Toke Høiland-Jørgensen
Yibo Zhao writes:
> On 2019-04-10 04:41, Toke Høiland-Jørgensen wrote:
>> Yibo Zhao writes:
>>
>>> On 2019-04-04 16:31, Toke Høiland-Jørgensen wrote:
>>>> Yibo Zhao writes:
>>>>
>>>>> On 2019-02-16 01:05, Toke Høiland-Jørgensen w
John Crispin writes:
> On 02/04/2019 11:50, Toke Høiland-Jørgensen wrote:
>> ieee80211_queue_skb() calls ieee80211_get_txq() which treats skb->data
>> like it contains an 802.11 header. That is probably not the intention
>> here, is it?
>>
>> I guess we cou
Yibo Zhao writes:
> On 2019-04-04 16:31, Toke Høiland-Jørgensen wrote:
>> Yibo Zhao writes:
>>
>>> On 2019-02-16 01:05, Toke Høiland-Jørgensen wrote:
>>>> This switches the airtime scheduler in mac80211 to use a virtual
>>>> time-based
>>
Dave Taht writes:
> On Thu, Apr 4, 2019 at 10:31 AM Toke Høiland-Jørgensen
> wrote:
>>
>> Yibo Zhao writes:
>>
>> > On 2019-02-16 01:05, Toke Høiland-Jørgensen wrote:
>> >> This switches the airtime scheduler in mac80211 to use a virtual
>>
Yibo Zhao writes:
> On 2019-02-16 01:05, Toke Høiland-Jørgensen wrote:
>> This switches the airtime scheduler in mac80211 to use a virtual
>> time-based
>> scheduler instead of the round-robin scheduler used before. This has a
>> couple of advantages:
>>
>&g
Johannes Berg writes:
> On Tue, 2019-04-02 at 11:50 +0200, Toke Høiland-Jørgensen wrote:
>
> [snip, you really should try that sometimes ;-)]
>
>> ieee80211_queue_skb() calls ieee80211_get_txq() which treats skb-
>> datalike it contains an 802.11 header. That is proba
John Crispin writes:
> From: Vasanthakumar Thiagarajan
>
> This patch adds a new transmit path for hardware that supports 802.11
> encapsulation offloading. In those cases 802.3a frames get passed
> directly to the driver allowing to hardware to handle the encapsulation.
>
> Certain features won
Signed-off-by: Felix Fietkau
Acked-by: Toke Høiland-Jørgensen
> ---
> net/mac80211/rx.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> index 295535b75184..60aac91e35d0 100644
> --- a/net/mac80211/rx.
Felix Fietkau writes:
> On 2019-03-18 23:14, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau writes:
>>
>>> On 2019-03-17 22:59, Toke Høiland-Jørgensen wrote:
>>>> Felix Fietkau writes:
>>>>> I've looked at ath9k (the only user at the
Felix Fietkau writes:
> On 2019-03-17 22:59, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau writes:
>>> I've looked at ath9k (the only user at the moment), and it seems to call
>>> the function in that way already: at PS wake or tx status time if it has
>&g
ing and airtime
> APIs")
> Signed-off-by: Felix Fietkau
Acked-by: Toke Høiland-Jørgensen
Felix Fietkau writes:
> On 2019-03-17 12:32, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau writes:
>>
>>> On 2019-03-16 23:28, Toke Høiland-Jørgensen wrote:
>>>> Felix Fietkau writes:
>>>>
>>>>> Performance improv
Felix Fietkau writes:
> Currently there is no way for the driver to signal to mac80211 that it should
> schedule a TXQ even if there are no packets on the mac80211 part of that
> queue.
> This is problematic if the driver has an internal retry queue to deal with
> software A-MPDU retry.
>
> This
Felix Fietkau writes:
> On 2019-03-16 23:28, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau writes:
>>
>>> Performance improvement and preparation for adding airtime fairness
>>> support
>>
>> Great to see this! Do you have a plan for the airtime f
Felix Fietkau writes:
> Performance improvement and preparation for adding airtime fairness
> support
Great to see this! Do you have a plan for the airtime fairness part?
I.e., how to get the airtime information?
Only one other comment, below.
> Signed-off-by: Felix Fietkau
> ---
> drivers/n
Felix Fietkau writes:
> When using iTXQ, tx sequence number allocation and statistics are run at
> dequeue time. Because of that, it is safe to enable NETIF_F_LLTX, which
> allows tx handlers to run on multiple CPUs in parallel.
Cool, didn't know about that flag.
Acked-by
Felix Fietkau writes:
> Reduces lock contention on enqueue/dequeue of iTXQ packets
>
> Signed-off-by: Felix Fietkau
Also reasonable.
Acked-by: Toke Høiland-Jørgensen
Felix Fietkau writes:
> Reduces lock contention on enqueue/dequeue of iTXQ packets
>
> Signed-off-by: Felix Fietkau
Seems reasonable.
Acked-by: Toke Høiland-Jørgensen
Felix Fietkau writes:
> skb->truesize can change due to memory reallocation or when adding extra
> fragments. Adjust fq->memory_usage accordingly
Nice catch.
Acked-by: Toke Høiland-Jørgensen
Johannes Berg writes:
> On Sun, 2019-03-10 at 20:21 -0700, Kevin Hayes wrote:
>> [resending after html mode got nacked..]
>>
>> Hi Johannes/Toke,
>> It would be fine with Kan and me to push the airtime fairness
>> discussion to later, to accomodate Toke.
>> Workshop fairness in action. :)
>
> :
uling
> list modifications.
>
> Signed-off-by: Felix Fietkau
Acked-by: Toke Høiland-Jørgensen
> include/net/mac80211.h | 49 --
> net/mac80211/tx.c | 44 ++---
> 2 files changed, 35 insertions(+), 58
Felix Fietkau writes:
> On 2019-03-13 23:55, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau writes:
>>
>>> Holding the lock around the entire duration of tx scheduling can
>>> create some nasty lock contention, especially when processing airtime
>>>
Felix Fietkau writes:
> Holding the lock around the entire duration of tx scheduling can
> create some nasty lock contention, especially when processing airtime
> information from the tx status or the rx path.
Right, I can see how that could become an issue at higher loads than
what I tested wit
Felix Fietkau writes:
> On 2019-03-08 12:05, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau writes:
>>
>>> On 2019-02-15 18:05, Toke Høiland-Jørgensen wrote:
>>>> This switches the airtime scheduler in mac80211 to use a virtual time-based
>>>>
Felix Fietkau writes:
> On 2019-02-15 18:05, Toke Høiland-Jørgensen wrote:
>> This switches the airtime scheduler in mac80211 to use a virtual time-based
>> scheduler instead of the round-robin scheduler used before. This has a
>> couple of advantages:
>>
>> - N
transmit.
To fix this, account airtime usage to the TID number from the original skb,
instead of the one in the hardware TX status report.
Reported-by: Miguel Catalan Cid
Signed-off-by: Toke Høiland-Jørgensen
---
I haven't been able to confirm that this also affects the old in-driver
airtime sche
Rajkumar Manoharan writes:
> On 2019-03-05 07:45, Toke Høiland-Jørgensen wrote:
>> Toke Høiland-Jørgensen writes:
>>
>>> This switches the airtime scheduler in mac80211 to use a virtual
>>> time-based
>>> scheduler instead of the round-robin sched
Toke Høiland-Jørgensen writes:
> This switches the airtime scheduler in mac80211 to use a virtual time-based
> scheduler instead of the round-robin scheduler used before. This has a
> couple of advantages:
>
> - No need to sync up the round-robin scheduler in firmware/hardware wit
Johannes Berg writes:
> On Fri, 2019-03-01 at 12:11 +0100, Toke Høiland-Jørgensen wrote:
>> Johannes Berg writes:
>>
>> > Please add your favourite topics to
>> >
>> > https://wireless.wiki.kernel.org/en/developers/summits/prague-2019
>> >
Johannes Berg writes:
> Please add your favourite topics to
>
> https://wireless.wiki.kernel.org/en/developers/summits/prague-2019
>
> I've added a few I think we should discuss at this stage, so also see if
> you have an opinion on those :-)
Cool! Could we schedule the scheduling and airtime fa
Kalle Valo writes:
> Toke Høiland-Jørgensen writes:
>
>> Kalle Valo writes:
>>
>>> Toke Høiland-Jørgensen writes:
>>>
>>>> YueHaibing writes:
>>>>
>>>>> Fixes gcc '-Wunused-but-set-variable' warning:
Kalle Valo writes:
> Toke Høiland-Jørgensen writes:
>
>> YueHaibing writes:
>>
>>> Fixes gcc '-Wunused-but-set-variable' warning:
>>>
>>> drivers/net/wireless/ath/ath9k/recv.c: In function 'ath_rx_count_airtime':
>>>
sed-but-set-variable]
>
> It's not used after 89cea7493a34 ("ath9k: Switch to mac80211 TXQ scheduling
> and airtime APIs"). Also remove related variables.
Ah, right, seems I forgot to clean that up. I wonder why I didn't get a
compiler warning for it. Anyway, nice catch :)
Acked-by: Toke Høiland-Jørgensen
-Toke
Johannes Berg writes:
> On Fri, 2019-02-22 at 14:40 +0100, Toke Høiland-Jørgensen wrote:
>>
>> And send it directly to stable, or does it need to go through you?
>
> I added a Cc: stable tag. So all you really need to do is wait for the
> emails telling you it fai
Johannes Berg writes:
> On Fri, 2019-02-22 at 14:06 +0100, Toke Høiland-Jørgensen wrote:
>> Johannes Berg writes:
>>
>> > Toke Høiland-Jørgensen wrote:
>> >
>> > > When we did the original tests for the optimal value of sk_pacing_shift,
>>
Johannes Berg writes:
> Toke Høiland-Jørgensen wrote:
>
>> When we did the original tests for the optimal value of sk_pacing_shift, we
>> came up with 6 ms of buffering as the default. Sadly, 6 is not a power of
>> two, so when picking the shift value I erred on the size
Ben Greear writes:
> On 2/21/19 9:15 AM, Toke Høiland-Jørgensen wrote:
>> Ben Greear writes:
>>
>>> On 2/21/19 8:37 AM, Toke Høiland-Jørgensen wrote:
>>>> Ben Greear writes:
>>>>
>>>>> On 2/21/19 8:10 AM, Kalle Valo wrote:
>&
overrides needed in the drivers.
Signed-off-by: Toke Høiland-Jørgensen
---
net/mac80211/main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 5055aeba5c5a..800e67615e2a 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
Ben Greear writes:
> On 2/21/19 8:37 AM, Toke Høiland-Jørgensen wrote:
>> Ben Greear writes:
>>
>>> On 2/21/19 8:10 AM, Kalle Valo wrote:
>>>> Toke Høiland-Jørgensen writes:
>>>>
>>>>> Grant Grundler writes:
>>>>&g
Ben Greear writes:
> On 2/21/19 8:10 AM, Kalle Valo wrote:
>> Toke Høiland-Jørgensen writes:
>>
>>> Grant Grundler writes:
>>>
>>>> On Thu, Sep 6, 2018 at 3:18 AM Toke Høiland-Jørgensen wrote:
>>>>>
>>>>> Grant Grund
Kalle Valo writes:
> Toke Høiland-Jørgensen writes:
>
>> Grant Grundler writes:
>>
>>> On Thu, Sep 6, 2018 at 3:18 AM Toke Høiland-Jørgensen wrote:
>>>>
>>>> Grant Grundler writes:
>>>>
>>>> >> And, well, Grant&
Grant Grundler writes:
> On Thu, Sep 6, 2018 at 3:18 AM Toke Høiland-Jørgensen wrote:
>>
>> Grant Grundler writes:
>>
>> >> And, well, Grant's data is from a single test in a noisy
>> >> environment where the time series graph shows that throu
ently backlogged, not all associated stations), so it
shouldn't be too big of an issue.
Signed-off-by: Toke Høiland-Jørgensen
---
This is basically the idea I mentioned earlier for a different way to
handle the airtime scheduling.
I've tested it on ath9k, where it achieves the same fairne
f the cb.
Fixes: 89cea7493a34 ("ath9k: Switch to mac80211 TXQ scheduling and airtime
APIs")
Signed-off-by: Toke Høiland-Jørgensen
---
drivers/net/wireless/ath/ath9k/xmit.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c
b/drivers/net/wir
This adds printing of the station TX duration (along with the existing RX
duration), and the airtime weight, both of which were added as part of the
airtime fairness patches that were recently merged into mac80211.
Signed-off-by: Toke Høiland-Jørgensen
---
station.c |9 +
1 file
1 - 100 of 491 matches
Mail list logo
