Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers

Johannes Berg writes: > On Mon, 2018-12-03 at 21:36 +0200, Toke Høiland-Jørgensen wrote: >> Hi Johannes >> >> I think your email can be basically summed up to: >> >> > [ ... ] but really I think it's a can of worms. >> >> ...right? :) > &

Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers

Hi Johannes I think your email can be basically summed up to: > [ ... ] but really I think it's a can of worms. ...right? :) I sort of had a feeling it would be, but thank you for spelling out in excruciating detail why that is so. Given this, I think I agree that it's not worth it for now,

Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers

Michał Kazior writes: > On Thu, 29 Nov 2018 at 14:00, Lorenzo Bianconi > wrote: > [...] >> > The other direction will probably be more difficult, at least if 802.11 >> > frames need to be built in software. It *might* be possible with the XDP >> > egress hook we are planning (with a suitable

Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers

Lorenzo Bianconi writes: >> Lorenzo Bianconi writes: >> >> > On Nov 28, Toke Høiland-Jørgensen wrote: >> >> Lorenzo Bianconi writes: >> >> >> >> >> Lorenzo Bianconi writes: >> >> >> >> >> >>

Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers

Lorenzo Bianconi writes: > On Nov 28, Toke Høiland-Jørgensen wrote: >> Lorenzo Bianconi writes: >> >> >> Lorenzo Bianconi writes: >> >> >> >> >> >> > This series is intended as a playground to start >> >> >

Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers

Lorenzo Bianconi writes: >> Lorenzo Bianconi writes: >> >> >> >> > This series is intended as a playground to start >> >> >> > experimenting/developing >> >> >> > with XDP/eBPF over WiFi and collect ideas/concerns about it. >> >> >> > Introduce XDP support to mt76x2e/mt76x0e drivers.

Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers

Lorenzo Bianconi writes: >> >> > This series is intended as a playground to start >> >> > experimenting/developing >> >> > with XDP/eBPF over WiFi and collect ideas/concerns about it. >> >> > Introduce XDP support to mt76x2e/mt76x0e drivers. Currently supported >> >> > actions are: >> >> > -

Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers

Michał Kazior writes: > On Wed, 28 Nov 2018 at 13:39, Toke Høiland-Jørgensen > wrote:[...] >> > This is an early stage implementation, at this point I would collect >> > other people opinions/concerns about using bpf/xdp directly on 802.11 >> >

Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers

Lorenzo Bianconi writes: >> Lorenzo Bianconi writes: >> >> > This series is intended as a playground to start experimenting/developing >> > with XDP/eBPF over WiFi and collect ideas/concerns about it. >> > Introduce XDP support to mt76x2e/mt76x0e drivers. Currently supported >> > actions are:

Re: [PATCH RFC v5 3/4] mac80211: Add airtime accounting and scheduling to TXQs

Rajkumar Manoharan writes: > On 2018-10-12 03:16, Toke Høiland-Jørgensen wrote: >> >> - Just loop with the smaller quantum until one of the stations go into >> the positive (what we do now). >> >> - Go through all active stations, find the one that is c

Re: [PATCH RFC v5 3/4] mac80211: Add airtime accounting and scheduling to TXQs

Rajkumar Manoharan writes: > On 2018-10-11 03:38, Toke Høiland-Jørgensen wrote: >> Rajkumar Manoharan writes: >> >>> Hmm... mine is bit different. txqs are refilled only once for all >>> txqs. >>> It will give more opportunity for non-served txqs.

Re: [PATCH RFC v5 3/4] mac80211: Add airtime accounting and scheduling to TXQs

Rajkumar Manoharan writes: > On 2018-10-10 04:15, Toke Høiland-Jørgensen wrote: >> Rajkumar Manoharan writes: >> >>> On 2018-10-09 05:32, Toke Høiland-Jørgensen wrote: >>>> This adds airtime accounting and scheduling to the mac8021

Re: [PATCH RFC v5 3/4] mac80211: Add airtime accounting and scheduling to TXQs

Rajkumar Manoharan writes: > On 2018-10-09 05:32, Toke Høiland-Jørgensen wrote: >> This adds airtime accounting and scheduling to the mac80211 TXQ >> scheduler. A new callback, ieee80211_sta_register_airtime(), is added >> that drivers can call to report airtime usage for

[PATCH RFC v5 0/4] Move TXQ scheduling and airtime fairness into mac80211

another RFC version instead of everyone having to suffer from my tardiness :) -Toke --- Toke Høiland-Jørgensen (4): mac80211: Add TXQ scheduling API cfg80211: Add airtime statistics and settings mac80211: Add airtime accounting and scheduling to TXQs ath9k: Switch

[PATCH RFC v5 2/4] cfg80211: Add airtime statistics and settings

Høiland-Jørgensen --- include/net/cfg80211.h | 10 +- include/uapi/linux/nl80211.h | 15 +++ net/wireless/nl80211.c | 29 + 3 files changed, 53 insertions(+), 1 deletion(-) diff --git a/include/net/cfg80211.h b/include/net/cfg80211

[PATCH RFC v5 1/4] mac80211: Add TXQ scheduling API

-robin, but a subsequent commit adds airtime fairness awareness to the scheduler. Signed-off-by: Toke Høiland-Jørgensen --- include/net/mac80211.h | 61 +--- net/mac80211/agg-tx.c |2 + net/mac80211/driver-ops.h |9 ++ net/mac80211

[PATCH RFC v5 3/4] mac80211: Add airtime accounting and scheduling to TXQs

. TXQs that are throttled by ieee802111_txq_may_transmit() will be woken up again by a check added to the ieee80211_wake_txqs() tasklet. Signed-off-by: Toke Høiland-Jørgensen --- include/net/mac80211.h | 52 +++ net/mac80211/cfg.c |3 ++ net/mac80211

[PATCH RFC v5 4/4] ath9k: Switch to mac80211 TXQ scheduling and airtime APIs

This moves the ath9k driver to use the mac80211 TXQ scheduling and airtime accounting APIs, removing the corresponding state tracking inside the driver. Signed-off-by: Toke Høiland-Jørgensen --- drivers/net/wireless/ath/ath9k/ath9k.h | 14 -- drivers/net/wireless/ath/ath9k/debug.c

Re: Tool to debug wifi pkt sniffs?

Ben Greear writes: > Hello, > > I often find myself wanting to figure out what equipment is to blame (and why) > in a wifi environment. > > I am thinking writing a tool that would parse a pcap file and look at frames > in enough detail to flag block-ack bugs, rate-ctrl bugs, guess at the >

Re: [Make-wifi-fast] [PATCH RFC v4 3/4] mac80211: Add airtime accounting and scheduling to TXQs

Rajkumar Manoharan writes: > On 2018-10-02 16:07, Rajkumar Manoharan wrote: >> On 2018-10-02 12:00, Toke Høiland-Jørgensen wrote: >>> Rajkumar Manoharan writes: >>>> I noticed a race condition b/w sta cleanup and kick_airtime tasklet. >>>>>>

Re: [Make-wifi-fast] [PATCH RFC v4 3/4] mac80211: Add airtime accounting and scheduling to TXQs

Rajkumar Manoharan writes: > On 2018-10-02 01:22, Toke Høiland-Jørgensen wrote: >> Rajkumar Manoharan writes: >> >>>> Great! I'll fold in the rest, test it with ath9k and submit as a >>>> proper >>>> patch :) >>>> >>> To

Re: [Make-wifi-fast] [PATCH RFC v4 3/4] mac80211: Add airtime accounting and scheduling to TXQs

Rajkumar Manoharan writes: >> Great! I'll fold in the rest, test it with ath9k and submit as a proper >> patch :) >> > Toke, > > I noticed a race condition b/w sta cleanup and kick_airtime tasklet. > How do you plan to exit kick_airtime gracefully during sta_cleanup? Ah, right, there's a lot

Re: [Make-wifi-fast] [PATCH RFC v4 3/4] mac80211: Add airtime accounting and scheduling to TXQs

On 28 September 2018 12:47:51 CEST, Rajkumar Manoharan wrote: >On 2018-09-28 03:35, Jonathan Morton wrote: >>> On 28 Sep, 2018, at 1:19 pm, Rajkumar Manoharan >>> wrote: >>> This is going to break fairness; we only want to increase deficits when all stations' deficits are

Re: [PATCH RFC v4 3/4] mac80211: Add airtime accounting and scheduling to TXQs

Rajkumar Manoharan writes: > On 2018-09-28 00:51, Toke Høiland-Jørgensen wrote: >> On 28 September 2018 07:29:03 CEST, Rajkumar Manoharan >> wrote: >>> On 2018-09-26 17:09, Rajkumar Manoharan wrote: >>>> On 2018-09-26 02:22, Toke Høiland-Jørgensen wro

Re: [PATCH RFC v4 3/4] mac80211: Add airtime accounting and scheduling to TXQs

Rajkumar Manoharan writes: > On 2018-09-16 10:42, Toke Høiland-Jørgensen wrote: >> This adds airtime accounting and scheduling to the mac80211 TXQ >> scheduler. A new callback, ieee80211_sta_register_airtime(), is added >> that drivers can call to report airtime usage for s

Re: [RFC v2] mac80211: budget outstanding airtime for transmission

Felix Fietkau writes: > On 2018-09-20 21:05, Rajkumar Manoharan wrote: >> Per frame airtime estimation could be used to track outstanding airtime >> of each txq and can be used to throttle ieee80211_tx_dequeue(). This >> mechanism on its own will get us the queue limiting and latency >>

Re: [PATCH RFC v4 0/4] Move TXQ scheduling into mac80211

Rajkumar Manoharan writes: > On 2018-09-16 10:42, Toke Høiland-Jørgensen wrote: >> Another update, addressing most of the concerns raised in the last >> round: >> >> - Added schedule_start()/end() functions that adds locking around the >> whole scheduling

Re: [RFC] mac80211: budget outstanding airtime for transmission

Rajkumar Manoharan writes: > Per frame airtime estimation could be used to track outstanding airtime > of each txq and can be used to throttle ieee80211_tx_dequeue(). This > mechanism on its own will get us the queue limiting and latency > reduction goodness for firmwares with deep queues. And

Re: [PATCH RFC v4 1/4] mac80211: Add TXQ scheduling API

Kalle Valo writes: > Toke Høiland-Jørgensen writes: > >>> Unfortunately ath10k is not reporting last_tx_rate in tx_status(). So >>> I also applied this "ath10k: report tx rate using ieee80211_tx_status" >>> change. >> >> Yeah, that and t

Re: [PATCH RFC v4 1/4] mac80211: Add TXQ scheduling API

Rajkumar Manoharan writes: > On 2018-09-18 13:41, Toke Høiland-Jørgensen wrote: >> Rajkumar Manoharan writes: >> >>>>> Also an option to add the node at head or tail would be preferred. >>>>> If >>>>> return_txq adds node at head

Re: [PATCH RFC v4 1/4] mac80211: Add TXQ scheduling API

Rajkumar Manoharan writes: >>> Also an option to add the node at head or tail would be preferred. If >>> return_txq adds node at head of list, then it is forcing the driver to >>> serve same txq until it becomes empty. Also this will not allow the >>> driver to send N frames from each txqs. >>

Re: [PATCH RFC v4 1/4] mac80211: Add TXQ scheduling API

Rajkumar Manoharan writes: > On 2018-09-16 10:42, Toke Høiland-Jørgensen wrote: >> +/** >> + * ieee80211_return_txq - return a TXQ previously acquired by >> ieee80211_next_txq() >> + * >> + * @hw: pointer as obtained from ieee80211_alloc_hw() >> + * @txq: p

[PATCH RFC v4 1/4] mac80211: Add TXQ scheduling API

-robin, but a subsequent commit adds airtime fairness awareness to the scheduler. Signed-off-by: Toke Høiland-Jørgensen --- include/net/mac80211.h | 62 +--- net/mac80211/agg-tx.c |2 + net/mac80211/driver-ops.h |9 ++ net/mac80211

[PATCH RFC v4 0/4] Move TXQ scheduling into mac80211

use if he wanted to do it himself :) -Toke --- Toke Høiland-Jørgensen (4): mac80211: Add TXQ scheduling API cfg80211: Add airtime statistics and settings mac80211: Add airtime accounting and scheduling to TXQs ath9k: Switch to mac80211 TXQ scheduling and airtime APIs d

[PATCH RFC v4 3/4] mac80211: Add airtime accounting and scheduling to TXQs

. TXQs that are throttled by ieee802111_txq_may_transmit() will be woken up again by a check added to the ieee80211_wake_txqs() tasklet. Signed-off-by: Toke Høiland-Jørgensen --- include/net/mac80211.h | 52 net/mac80211/cfg.c |3 ++ net/mac80211

[PATCH RFC v4 2/4] cfg80211: Add airtime statistics and settings

Høiland-Jørgensen --- include/net/cfg80211.h | 10 +- include/uapi/linux/nl80211.h | 15 +++ net/wireless/nl80211.c | 29 + 3 files changed, 53 insertions(+), 1 deletion(-) diff --git a/include/net/cfg80211.h b/include/net/cfg80211

[PATCH RFC v4 4/4] ath9k: Switch to mac80211 TXQ scheduling and airtime APIs

This moves the ath9k driver to use the mac80211 TXQ scheduling and airtime accounting APIs, removing the corresponding state tracking inside the driver. Signed-off-by: Toke Høiland-Jørgensen --- drivers/net/wireless/ath/ath9k/ath9k.h | 14 -- drivers/net/wireless/ath/ath9k/debug.c

Re: [PATCH RFC v3 0/4] Move TXQ scheduling into mac80211

Kan Yan writes: >> I think this is a great approach, that we should definitely adopt in >> mac80211. However, I'm not sure the outstanding airtime limiting should >> be integrated into the fairness scheduling, since there are drivers such >> as ath9k that don't need it. >> >> Rather, I'd propose

Re: [PATCH RFC v3 2/4] mac80211: Add airtime accounting and scheduling to TXQs

Rajkumar Manoharan writes: > On 2018-09-10 04:13, Toke Høiland-Jørgensen wrote: >> Johannes Berg writes: >>>> - txqi->flags & (1<>>> "RUN", >>>> - txqi->flags & (1<>&

Re: [PATCH RFC v3 1/4] mac80211: Add TXQ scheduling API

Johannes Berg writes: > On Mon, 2018-09-10 at 17:00 +0200, Toke Høiland-Jørgensen wrote: > >> > Do we even need end_schedule()? It's hard to pass multiple things to a >> > single call (do you build a list?), so having >> > >> >start_schedule()

Re: [PATCH RFC v3 1/4] mac80211: Add TXQ scheduling API

Johannes Berg writes: > On Mon, 2018-09-10 at 15:18 +0200, Toke Høiland-Jørgensen wrote: > >> If we have the start_schedule() / end_schedule() pair anyway, the latter >> could notify any TXQs that became eligible during the scheduling round. > > Do we even need end_sched

Re: [PATCH RFC v3 1/4] mac80211: Add TXQ scheduling API

Johannes Berg writes: > On Mon, 2018-09-10 at 15:08 +0200, Toke Høiland-Jørgensen wrote: >> Johannes Berg writes: >> >> > On Mon, 2018-09-10 at 14:39 +0200, Toke Høiland-Jørgensen wrote: >> > >> > > > From then on, right now we basically jus

Re: [PATCH RFC v3 1/4] mac80211: Add TXQ scheduling API

Johannes Berg writes: > On Mon, 2018-09-10 at 14:39 +0200, Toke Høiland-Jørgensen wrote: > >> > From then on, right now we basically just try to refill the hardware >> > queue from the TXQ whenever the hardware releases frames from that >> > queue. If there are n

Re: [PATCH RFC v3 1/4] mac80211: Add TXQ scheduling API

Johannes Berg writes: > On Mon, 2018-09-10 at 12:57 +0200, Toke Høiland-Jørgensen wrote: >> Johannes Berg writes: >> >> > On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote: >> > > >> > > Usage of the new API is

Re: [PATCH RFC v3 0/4] Move TXQ scheduling into mac80211

Johannes Berg writes: > On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote: >> >> A few things that were discussed in the last round that I did *not* change: > > Thanks for this list btw. > >> - I did not add any locking around next_txq()

Re: [PATCH RFC v3 0/4] Move TXQ scheduling into mac80211

Johannes Berg writes: > On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote: > >> - I didn't get rid of the register_airtime() callback. As far as I can tell, >> only iwlwifi uses the tx_time field in the struct tx_info. Which means that >>

Re: [PATCH RFC v3 3/4] cfg80211: Add airtime statistics and settings

Johannes Berg writes: > On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote: >> This adds airtime statistics to the cfg80211 station dump, and also adds a >> new >> parameter to set the airtime weight of each station. The latter allows >> userspa

Re: [PATCH RFC v3 2/4] mac80211: Add airtime accounting and scheduling to TXQs

Johannes Berg writes: > On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote: >> >> +/** >> + * ieee80211_airtime_may_transmit - check whether TXQ is allowed to transmit >> + * >> + * This function is used to check whether given txq is allowed to t

Re: [PATCH RFC v3 1/4] mac80211: Add TXQ scheduling API

Johannes Berg writes: > On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote: > >> +/** >> + * ieee80211_next_txq - get next tx queue to pull packets from >> + * >> + * @hw: pointer as obtained from ieee80211_alloc_hw() >> + * @ac: AC number t

Re: [PATCH RFC v3 1/4] mac80211: Add TXQ scheduling API

Johannes Berg writes: > On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote: >> >> Usage of the new API is optional, so drivers can be ported one at a time. > > With the 1:1 hardware queue/txq mapping in iwlwifi (we're close to > getting that patch in, though

Re: [PATCH RFC v3 0/4] Move TXQ scheduling into mac80211

Kan Yan writes: > Hi Toke, > > It is great to see finally there will be a general airtime fairness > support in mac80211. I feel this patch set could still use some > improvements to make it works better with 11ac drivers like ath10k. I > did a version of airtime fairness in the ath10k driver

[PATCH RFC v3 1/4] mac80211: Add TXQ scheduling API

-by: Toke Høiland-Jørgensen --- include/net/mac80211.h | 45 ++--- net/mac80211/agg-tx.c |2 + net/mac80211/driver-ops.h |7 + net/mac80211/ieee80211_i.h |9 +++ net/mac80211/main.c|4 +++ net/mac80211/sta_info.c|2

[PATCH RFC v3 4/4] ath9k: Switch to mac80211 TXQ scheduling and airtime APIs

This moves the ath9k driver to use the mac80211 TXQ scheduling and airtime accounting APIs, removing the corresponding state tracking inside the driver. Signed-off-by: Toke Høiland-Jørgensen --- drivers/net/wireless/ath/ath9k/ath9k.h | 14 -- drivers/net/wireless/ath/ath9k/debug.c

[PATCH RFC v3 2/4] mac80211: Add airtime accounting and scheduling to TXQs

()) in a way that enforces airtime fairness between active stations. This scheduling works the same way as the ath9k in-driver airtime fairness scheduling. If no airtime usage is reported by the driver, the scheduler will default to round-robin scheduling. Signed-off-by: Toke Høiland-Jørgensen --- include

[PATCH RFC v3 3/4] cfg80211: Add airtime statistics and settings

This adds airtime statistics to the cfg80211 station dump, and also adds a new parameter to set the airtime weight of each station. The latter allows userspace to implement policies for different stations by varying their weights. Signed-off-by: Toke Høiland-Jørgensen --- include/net/cfg80211.h

[PATCH RFC v3 0/4] Move TXQ scheduling into mac80211

. So I'll hold off on that for a bit more. -Toke --- Toke Høiland-Jørgensen (4): mac80211: Add TXQ scheduling API mac80211: Add airtime accounting and scheduling to TXQs cfg80211: Add airtime statistics and settings ath9k: Switch to mac80211 TXQ scheduling and airtime APIs

Re: [PATCH] mac80211: TDLS: fix skb queue/priority assignment

Johannes Berg writes: > On Wed, 2018-09-05 at 14:32 +0200, Toke Høiland-Jørgensen wrote: >> Johannes Berg writes: >> >> > On Wed, 2018-09-05 at 13:41 +0200, Johannes Berg wrote: >> > > On Wed, 2018-09-05 at 13:40 +0200, Toke Høiland-Jørgensen wrote: >>

Re: [PATCH] mac80211: TDLS: fix skb queue/priority assignment

Johannes Berg writes: > On Wed, 2018-09-05 at 13:34 +0200, Johannes Berg wrote: >> From: Johannes Berg >> >> If the TDLS setup happens over a connection to an AP that >> doesn't have QoS, we nevertheless assign a non-zero TID >> (skb->priority) and queue mapping, which may confuse us or >>

Re: [PATCH] mac80211: use non-zero TID only for QoS frames

Johannes Berg writes: > On Wed, 2018-09-05 at 13:07 +0200, Toke Høiland-Jørgensen wrote: > >> > Felix wasn't really convinced, I think. He also pointed out some drivers >> > use skb->priority without checking anything, but I'm not sure we can >> > really

Re: [PATCH] mac80211: use non-zero TID only for QoS frames

Johannes Berg writes: > On Wed, 2018-09-05 at 11:56 +0200, Toke Høiland-Jørgensen wrote: > >> > So basically this gets rid of a corner case that we shouldn't have. >> > Either we should decide that using different TXQs is *always* correct >> > for non-QoS, or -

Re: [PATCH] mac80211: fix pending queue hang due to TX_DROP

false due to > packet drops or power-save buffering in the tx handlers. In the > past, this function would return true in such cases, and the change > to false doesn't seem to be intentional. Can confirm that this was not intentional; nice catch! :) Acked-by: Toke Høiland-Jørgensen -Toke

Re: [PATCH] mac80211: use non-zero TID only for QoS frames

Johannes Berg writes: > On Wed, 2018-09-05 at 11:47 +0200, Toke Høiland-Jørgensen wrote: >> Johannes Berg writes: >> >> > From: Johannes Berg >> > >> > Some frames may have a non-zero skb->priority assigned by >> > mac80211 internal

Re: [PATCH] mac80211: use non-zero TID only for QoS frames

Johannes Berg writes: > From: Johannes Berg > > Some frames may have a non-zero skb->priority assigned by > mac80211 internally, e.g. TDLS setup frames, regardless of > support for QoS. > > Currently, we set skb->priority to 0 for all data frames. > Note that there's a comment that this is

Re: [RFC v2 2/4] mac80211: Add airtime accounting and scheduling to TXQs

Johannes Berg writes: >> > Perhaps then it should just be fractional? i.e. 8.8 bits or so?, so >> > the default would be 1.0 (0x0100) and then you could scale down to 0.5 >> > (0x0080) etc? >> >> Hmm, that's an interesting idea. I'll have to run some numbers to see >> how the precision holds up

Re: [RFC v2 2/4] mac80211: Add airtime accounting and scheduling to TXQs

Johannes Berg writes: > On Wed, 2018-08-29 at 11:27 +0200, Toke Høiland-Jørgensen wrote: > >> Hmm, the problem with a higher weight is that weight*quantum becomes the >> time each station is scheduled, so having a higher value means higher >> latency. This could be fixed

Re: [RFC v2 1/4] mac80211: Add TXQ scheduling API

Johannes Berg writes: > On Wed, 2018-08-29 at 11:22 +0200, Toke Høiland-Jørgensen wrote: > >> > We're also working on adding a TXQ for (bufferable) management packets >> > - I wonder how that should interact here? Always be scheduled first? >> >> Ah, coo

Re: [RFC v2 2/2] mac80211: manage txq transmission based on airtime deficit

Rajkumar Manoharan writes: > Once a txq is selected for transmission by next_txq(), all data from > txq are dequeued by driver till hardware descriptors are drained. > i.e the driver is still allowed to dequeue frames from txq even when > its fairness deficit goes negative during transmission.

Re: [RFC v2 2/4] mac80211: Add airtime accounting and scheduling to TXQs

Johannes Berg writes: > On Mon, 2018-07-09 at 18:37 +0200, Toke Høiland-Jørgensen wrote: >> >> @@ -427,6 +428,8 @@ struct sta_info *sta_info_alloc(struct >> ieee80211_sub_if_data *sdata, >> sta->cparams.interval = MS2TIME(100); >> sta-&

Re: [RFC v2 1/4] mac80211: Add TXQ scheduling API

Johannes Berg writes: > Rather belatedly reviewing this too ... > >> + * The driver can't access the queue directly. To dequeue a frame from a >> + * txq, it calls ieee80211_tx_dequeue(). Whenever mac80211 adds a new frame >> to a >> + * queue, it calls the .wake_tx_queue driver op. >> + * >> +

Re: [RFC 3/3] mac80211: add ieee80211_reorder_txq

Rajkumar Manoharan writes: >>> As mentioned earlier, next_txq() can not be used for fetching txq >>> directly. So reorder_txq() needs to take care of refilling txq after >>> serving them. >> >> Yeah, I got that; but see above. Unless there's a guarantee that the >> push/pull mechanism will be

Re: [RFC 3/3] mac80211: add ieee80211_reorder_txq

Rajkumar Manoharan writes: > On 2018-08-21 05:24, Toke Høiland-Jørgensen wrote: >> Rajkumar Manoharan writes: >> >>> This allows the driver to refill airtime fairness deficit >>> where the driver will not access txqs by ieee80211_next_txq. >>> In

Re: [RFC 3/3] mac80211: add ieee80211_reorder_txq

Rajkumar Manoharan writes: > This allows the driver to refill airtime fairness deficit > where the driver will not access txqs by ieee80211_next_txq. > In tx push mode data path, high priority txqs will be scheduled > for data transmission by ieee80211_next_txq and driver will not > prioritize

Re: [PATCH] mac80211: Run TXQ teardown code before de-registering interfaces

Arend van Spriel writes: > On 8/13/2018 2:16 PM, Toke Høiland-Jørgensen wrote: >> The TXQ teardown code can reference the vif data structures that are >> stored in the netdev private memory area if there are still packets on >> the queue when it is being freed. Since the TXQ

[PATCH] mac80211: Run TXQ teardown code before de-registering interfaces

the TXQ teardown code to earlier in ieee80211_unregister_hw(). Reported-by: Ben Greear Tested-by: Ben Greear Signed-off-by: Toke Høiland-Jørgensen --- net/mac80211/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mac80211/main.c b/net/mac80211/main.c index e054a2fd8d38

Re: use-after free bug in hacked 4.16 kernel, related to fq_flow_dequeue

Ben Greear writes: > On 08/02/2018 01:20 PM, Toke Høiland-Jørgensen wrote: >> Ben Greear writes: >> >>> On 08/02/2018 12:45 PM, Toke Høiland-Jørgensen wrote: >>>> Ben Greear writes: >>>> >>>>> This is from my hacked kernel, co

Re: use-after free bug in hacked 4.16 kernel, related to fq_flow_dequeue

Ben Greear writes: > On 08/02/2018 12:45 PM, Toke Høiland-Jørgensen wrote: >> Ben Greear writes: >> >>> This is from my hacked kernel, could be my fault. I thought the fq >>> guys might want to know however... >> >> Hmm, nothing obvious comes to mind

Re: use-after free bug in hacked 4.16 kernel, related to fq_flow_dequeue

Ben Greear writes: > This is from my hacked kernel, could be my fault. I thought the fq > guys might want to know however... Hmm, nothing obvious comes to mind; fq_flow_dequeue() just dequeues a packet from the queue; it only has two memory derefs, to fq->lock and flow->queue. Don't see why

Re: [RFC v2 1/4] mac80211: Add TXQ scheduling API

Rajkumar Manoharan writes: >>> A simple change in argument may break algo. What would be seqno of >>> first packet of txq if queue_skb() isn't reset seqno? >> >> It would be 0, which would be less than the current seqno in all cases >> except just when the seqno counter wraps. >> > > One point

Re: [RFC v2 1/4] mac80211: Add TXQ scheduling API

Rajkumar Manoharan writes: > On 2018-07-21 13:54, Toke Høiland-Jørgensen wrote: >> Rajkumar Manoharan writes: >> >>> On 2018-07-19 07:18, Toke Høiland-Jørgensen wrote: >>>> Rajkumar Manoharan writes: >>>> >>>>> On 2018-07-13

Re: [RFC v2 1/4] mac80211: Add TXQ scheduling API

Rajkumar Manoharan writes: > On 2018-07-19 07:18, Toke Høiland-Jørgensen wrote: >> Rajkumar Manoharan writes: >> >>> On 2018-07-13 06:39, Toke Høiland-Jørgensen wrote: >>>> Rajkumar Manoharan writes: > >>>> It is not generally predictabl

Re: [RFC v2 1/4] mac80211: Add TXQ scheduling API

Rajkumar Manoharan writes: > On 2018-07-13 06:39, Toke Høiland-Jørgensen wrote: >> Rajkumar Manoharan writes: >> > [...] > >>> Hmm... I thought driver will call ieee80211_schedule_txq when it runs >>> out of hardware descriptor and break the loop. The ser

Re: [RFC v2 1/4] mac80211: Add TXQ scheduling API

Rajkumar Manoharan writes: > On 2018-07-12 16:13, Toke Høiland-Jørgensen wrote: >> Rajkumar Manoharan writes: >> >>> On 2018-07-11 13:48, Toke Høiland-Jørgensen wrote: >>>> Rajkumar Manoharan writes: >>>> >>

Re: [RFC v2 1/4] mac80211: Add TXQ scheduling API

Rajkumar Manoharan writes: > On 2018-07-11 13:48, Toke Høiland-Jørgensen wrote: >> Rajkumar Manoharan writes: >> >>> On 2018-07-09 09:37, Toke Høiland-Jørgensen wrote: >>> [...] >>>> +/** >>>> + * ieee80211_schedule_txq - add txq to s

Re: [RFC v2 1/4] mac80211: Add TXQ scheduling API

Rajkumar Manoharan writes: > On 2018-07-09 09:37, Toke Høiland-Jørgensen wrote: > [...] >> +/** >> + * ieee80211_schedule_txq - add txq to scheduling loop >> + * >> + * @hw: pointer as obtained from ieee80211_alloc_hw() >> + * @txq: pointer obtain

Re: [PATCHv2] mac80211: add stop/start logic for software TXQs

Manikanta Pubbisetty writes: > On 7/10/2018 8:52 PM, Toke Høiland-Jørgensen wrote: >> Manikanta Pubbisetty writes: >> >>> On 7/10/2018 6:28 PM, Toke Høiland-Jørgensen wrote: >>> >>>>> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/i

Re: [PATCHv2] mac80211: add stop/start logic for software TXQs

> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h > index 172aeae..d07f7f9 100644 > --- a/net/mac80211/ieee80211_i.h > +++ b/net/mac80211/ieee80211_i.h > @@ -818,6 +818,7 @@ enum txq_info_flags { > IEEE80211_TXQ_STOP, > IEEE80211_TXQ_AMPDU, >

Re: mac80211: AQM and block_tx

Sven Eckelmann writes: > On Donnerstag, 5. Juli 2018 10:47:11 CEST Sven Eckelmann wrote: >> Hi Toke, >> >> we are currently testing DFS with ath10k and noticed that AQM seems to >> ignore >> cfg80211_csa_settings->block_tx. Problem is now that the channel switch is >> started on a detected

[RFC v2 4/4] ath9k: Switch to mac80211 TXQ scheduling and airtime APIs

This moves the ath9k driver to use the mac80211 TXQ scheduling and airtime accounting APIs, removing the corresponding state tracking inside the driver. Signed-off-by: Toke Høiland-Jørgensen --- drivers/net/wireless/ath/ath9k/ath9k.h | 14 -- drivers/net/wireless/ath/ath9k/debug.c

[RFC v2 2/4] mac80211: Add airtime accounting and scheduling to TXQs

airtime policies. If the extended feature is not set, the scheduler will default to round-robin scheduling. Signed-off-by: Toke Høiland-Jørgensen --- include/net/mac80211.h | 28 include/uapi/linux/nl80211.h |3 ++ net/mac80211/debugfs.c |3 ++ net

[RFC v2 3/4] cfg80211: Add airtime statistics and settings

This adds airtime statistics to the cfg80211 station dump, and also adds a new parameter to set the airtime weight of each station. The latter allows userspace to implement policies for different stations by varying their weights. Signed-off-by: Toke Høiland-Jørgensen --- include/net/cfg80211.h

[RFC v2 1/4] mac80211: Add TXQ scheduling API

at a time. Signed-off-by: Toke Høiland-Jørgensen --- include/net/mac80211.h | 50 +--- net/mac80211/agg-tx.c |2 + net/mac80211/ieee80211_i.h |7 net/mac80211/main.c|3 ++ net/mac80211/sta_info.c|3 ++ net/mac80211/tx.c

[RFC v2 0/4] Move TXQ scheduling into mac80211

also incorporates weights into the scheduling, which allows userspace to implement policies for how airtime is divided between stations. I have a patch series for hostapd to implement configurable policies, that I will post separately once the kernel side is in place. --- Toke Høiland-Jørgensen (4

Re: [PATCH] mac80211: don't put null-data frames on the normal TXQ

Johannes Berg writes: > On Wed, 2018-07-04 at 09:26 +0200, Toke Høiland-Jørgensen wrote: >> Johannes Berg writes: >> >> > I see no evidence of ath9k doing this correctly, so this might fix a >> > bug there, but I may have missed it. >> >> at

Re: [PATCH] mac80211: don't put null-data frames on the normal TXQ

Johannes Berg writes: > I see no evidence of ath9k doing this correctly, so this might fix a > bug there, but I may have missed it. ath9k does check for this, in ath_tx_sched_aggr() and in ath_tx_form_aggr(); it'll check for the IEEE80211_TX_CTL_AMPDU flag, and stop building the current

Re: [PATCH] mac80211: don't put null-data frames on the normal TXQ

Johannes Berg writes: > From: Johannes Berg > > Since (QoS) NDP frames shouldn't be put into aggregation nor are > assigned real sequence numbers, etc. it's better to treat them as > non-data packets and not put them on the normal TXQs, for example > when building A-MPDUs they need to be

Re: [PATCH] mac80211: add stop/start logic for software TXQs

Manikanta Pubbisetty writes: > On 6/26/2018 4:55 PM, Toke Høiland-Jørgensen wrote: >> Manikanta Pubbisetty writes: >> >>> We can still invoke netif stop/wake APIs when wake_tx_queue is >>> implemented but this could lead to packet drops in network layer; >>

Re: [PATCH] mac80211: add stop/start logic for software TXQs

Manikanta Pubbisetty writes: > We can still invoke netif stop/wake APIs when wake_tx_queue is > implemented but this could lead to packet drops in network layer; > adding stop/start logic for software TXQs in mac80211 instead makes > more sense; the change proposed adds the same in mac80211. I

RE: [PATCH 0/4] cfg80211/mac80211: Add support to configure and monitor txrate threshold

Tamizh Chelvam Raja writes: >> This patchsets introduced new NL command and api to support >> configuring txrate threshold for the connected stations and api to >> notify userspace application upon crossing the configured txrate threshold. >> This will be useful for the application which

Re: [PATCH 0/4] cfg80211/mac80211: Add support to configure and monitor txrate threshold

Tamizh chelvam writes: > This patchsets introduced new NL command and api to support > configuring txrate threshold for the connected stations and api to > notify userspace application upon crossing the configured txrate threshold. > This will be useful for the application which requires >

Re: [PATCH] mac80211: Move up init of TXQs

Niklas Cassel writes: > Tested-by: Niklas Cassel Great, thanks! -Toke

  1   2   3   4   >