From: Johannes Berg <johannes@sipsolutions.net>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>,
make-wifi-fast@lists.bufferbloat.net,
linux-wireless@vger.kernel.org
Subject: Re: [Make-wifi-fast] [RFC 1/3] mac80211: Add TXQ scheduling API
Date: Tue, 10 Oct 2017 17:53:43 +0200 [thread overview]
Message-ID: <1507650823.26041.70.camel@sipsolutions.net> (raw)
In-Reply-To: <20171010140208.1515-1-toke@toke.dk> (sfid-20171010_160341_258014_BDC1BDA8)
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(IEEE80211_TXQ_AMPDU, &txqi->flags);
>
> clear_bit(IEEE80211_TXQ_STOP, &txqi->flags);
> + ieee80211_schedule_txq(&sta->sdata->local->hw, txq);
> +
> local_bh_disable();
> rcu_read_lock();
> - drv_wake_tx_queue(sta->sdata->local, txqi);
> + drv_wake_tx_queue(sta->sdata->local);
> rcu_read_unlock();
> local_bh_enable();
It seems like there could be some sort of TX batching here - maybe only
call the driver if the queue was actually scheduled?
Return true/false from ieee80211_schedule_txq() depending on whether it
was added or not, and then call the driver only if it was added just
now? That way, we can save a bunch of driver calls, batching the TX.
> @@ -1121,6 +1122,9 @@ struct ieee80211_local {
> struct codel_vars *cvars;
> struct codel_params cparams;
>
> + struct list_head active_txqs;
> + spinlock_t active_txq_lock;
Is there much point in having a separate lock? We probably need the fq
lock in most places related to this anyway?
> +++ b/net/mac80211/sta_info.c
> @@ -1250,8 +1250,9 @@ void ieee80211_sta_ps_deliver_wakeup(struct
> sta_info *sta)
> if (!txq_has_queue(sta->sta.txq[i]))
> continue;
>
> - drv_wake_tx_queue(local, to_txq_info(sta-
> >sta.txq[i]));
> + ieee80211_schedule_txq(&local->hw, sta-
> >sta.txq[i]);
> }
> + drv_wake_tx_queue(local);
Again, calling the driver could be conditional on having done any
interesting work.
> @@ -1524,7 +1526,8 @@ static bool ieee80211_queue_skb(struct
> ieee80211_local *local,
> ieee80211_txq_enqueue(local, txqi, skb);
> spin_unlock_bh(&fq->lock);
>
> - drv_wake_tx_queue(local, txqi);
> + ieee80211_schedule_txq(&local->hw, &txqi->txq);
> + drv_wake_tx_queue(local);
ditto
> +void ieee80211_schedule_txq(struct ieee80211_hw *hw,
> + struct ieee80211_txq *txq)
> +{
> + struct ieee80211_local *local = hw_to_local(hw);
> + struct txq_info *txqi = to_txq_info(txq);
> +
> + spin_lock_bh(&local->active_txq_lock);
> +
> + if (!list_empty(&txqi->schedule_order))
> + list_add_tail(&txqi->schedule_order, &local-
> >active_txqs);
What's with the !list_empty()? Seems inverted to me? You need to add it
if it's empty?
Also maybe you should only do that if the TXQ isn't *empty*, so the
driver could call this unconditionally?
> +struct ieee80211_txq *ieee80211_next_txq(struct ieee80211_hw *hw)
> +{
> + struct ieee80211_local *local = hw_to_local(hw);
> + struct txq_info *txqi = NULL;
> +
> + spin_lock_bh(&local->active_txq_lock);
> +
> + if (list_empty(&local->active_txqs))
> + goto out;
> +
> + txqi = list_first_entry(&local->active_txqs, struct
> txq_info, schedule_order);
> + list_del_init(&txqi->schedule_order);
> +
> +out:
> + spin_unlock_bh(&local->active_txq_lock);
> +
> + return &txqi->txq;
You forgot
if (!txqi)
return NULL;
johannes
next prev parent reply other threads:[~2017-10-10 15:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-10 14:02 Toke Høiland-Jørgensen
2017-10-10 14:02 ` [Make-wifi-fast] [RFC 2/3] ath9k: Move to mac80211 " Toke Høiland-Jørgensen
2017-10-10 15:54 ` Johannes Berg
2017-10-10 14:02 ` [Make-wifi-fast] [RFC 3/3] ath10k: " Toke Høiland-Jørgensen
2017-10-10 15:53 ` Johannes Berg [this message]
2017-10-10 17:51 ` [Make-wifi-fast] [RFC 1/3] mac80211: Add " Toke Høiland-Jørgensen
2017-10-11 8:46 ` Johannes Berg
2017-10-11 13:54 ` Toke Høiland-Jørgensen
2017-10-10 16:05 ` Johannes Berg
2017-10-10 18:04 ` Toke Høiland-Jørgensen
2017-10-11 8:44 ` Johannes Berg
2017-10-11 14:06 ` Toke Høiland-Jørgensen
2017-10-11 14:15 ` Johannes Berg
2017-10-11 14:29 ` Toke Høiland-Jørgensen
2017-10-11 14:34 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1507650823.26041.70.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=make-wifi-fast@lists.bufferbloat.net \
--cc=toke@toke.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox