From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Yibo Zhao <yiboz@codeaurora.org>
Cc: linux-wireless-owner@vger.kernel.org,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
Subject: Re: [PATCH 2/4] mac80211: defer txqs removal from rbtree
Date: Tue, 24 Sep 2019 09:26:28 +0200 [thread overview]
Message-ID: <87r24640kb.fsf@toke.dk> (raw)
In-Reply-To: <1b3eab1f2481e0102b284f133605c6c4@codeaurora.org>
>> Hmm, yeah, I guess we could end up with a loop like that as well.
>> Keeping the schedule_round would be a way to fix it, but I'm not sure
>> we
>> should just skip that station; maybe we should just end the round
>> instead?
> I am not sure. I believe, in some cases, the rest of the nodes which
> could be most of the nodes in the tree will not have the chance to be
> scheduled in this round.
My guess would be that it doesn't really matter, because in most cases
each schedule round will only actually end up queueing packets from one
or two stations; as the driver will pull multiple packets from that one
station which will often fill up the firmware queues (especially once we
start throttling that with the AQL stuff).
So I guess we can just skip TXQs that we've already seen this scheduling
round, and let the v_t compare determine transmit eligibility :)
-Toke
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
WARNING: multiple messages have this Message-ID (diff)
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Yibo Zhao <yiboz@codeaurora.org>
Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org,
linux-wireless-owner@vger.kernel.org
Subject: Re: [PATCH 2/4] mac80211: defer txqs removal from rbtree
Date: Tue, 24 Sep 2019 09:26:28 +0200 [thread overview]
Message-ID: <87r24640kb.fsf@toke.dk> (raw)
In-Reply-To: <1b3eab1f2481e0102b284f133605c6c4@codeaurora.org>
>> Hmm, yeah, I guess we could end up with a loop like that as well.
>> Keeping the schedule_round would be a way to fix it, but I'm not sure
>> we
>> should just skip that station; maybe we should just end the round
>> instead?
> I am not sure. I believe, in some cases, the rest of the nodes which
> could be most of the nodes in the tree will not have the chance to be
> scheduled in this round.
My guess would be that it doesn't really matter, because in most cases
each schedule round will only actually end up queueing packets from one
or two stations; as the driver will pull multiple packets from that one
station which will often fill up the firmware queues (especially once we
start throttling that with the AQL stuff).
So I guess we can just skip TXQs that we've already seen this scheduling
round, and let the v_t compare determine transmit eligibility :)
-Toke
next prev parent reply other threads:[~2019-09-24 7:26 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-16 13:09 [PATCH 1/4] mac80211: Switch to a virtual time-based airtime scheduler Yibo Zhao
2019-09-16 13:09 ` Yibo Zhao
2019-09-16 13:09 ` [PATCH 2/4] mac80211: defer txqs removal from rbtree Yibo Zhao
2019-09-16 13:09 ` Yibo Zhao
2019-09-17 21:10 ` Toke Høiland-Jørgensen
2019-09-17 21:10 ` Toke Høiland-Jørgensen
2019-09-18 10:27 ` Yibo Zhao
2019-09-18 10:27 ` Yibo Zhao
2019-09-18 11:23 ` Toke Høiland-Jørgensen
2019-09-18 11:23 ` Toke Høiland-Jørgensen
2019-09-19 9:56 ` Yibo Zhao
2019-09-19 9:56 ` Yibo Zhao
2019-09-19 10:37 ` Toke Høiland-Jørgensen
2019-09-19 10:37 ` Toke Høiland-Jørgensen
2019-09-20 8:29 ` Yibo Zhao
2019-09-20 8:29 ` Yibo Zhao
2019-09-20 9:15 ` Toke Høiland-Jørgensen
2019-09-20 9:15 ` Toke Høiland-Jørgensen
2019-09-21 10:49 ` Yibo Zhao
2019-09-21 10:49 ` Yibo Zhao
2019-09-21 11:27 ` Toke Høiland-Jørgensen
2019-09-21 11:27 ` Toke Høiland-Jørgensen
2019-09-21 11:53 ` Yibo Zhao
2019-09-21 11:53 ` Yibo Zhao
2019-09-21 12:22 ` Yibo Zhao
2019-09-21 12:22 ` Yibo Zhao
2019-09-21 13:02 ` Toke Høiland-Jørgensen
2019-09-21 13:02 ` Toke Høiland-Jørgensen
2019-09-21 13:24 ` Yibo Zhao
2019-09-21 13:24 ` Yibo Zhao
2019-09-21 14:00 ` Toke Høiland-Jørgensen
2019-09-21 14:00 ` Toke Høiland-Jørgensen
2019-09-22 5:19 ` Yibo Zhao
2019-09-22 5:19 ` Yibo Zhao
2019-09-23 10:47 ` Toke Høiland-Jørgensen
2019-09-23 10:47 ` Toke Høiland-Jørgensen
2019-09-23 11:42 ` Kalle Valo
2019-09-23 11:42 ` Kalle Valo
2019-09-23 16:39 ` Toke Høiland-Jørgensen
2019-09-23 16:39 ` Toke Høiland-Jørgensen
2019-09-24 5:27 ` Kalle Valo
2019-09-24 5:27 ` Kalle Valo
2019-09-24 7:23 ` Toke Høiland-Jørgensen
2019-09-24 7:23 ` Toke Høiland-Jørgensen
2019-09-24 2:45 ` Yibo Zhao
2019-09-24 2:45 ` Yibo Zhao
2019-09-24 7:26 ` Toke Høiland-Jørgensen [this message]
2019-09-24 7:26 ` Toke Høiland-Jørgensen
2019-09-24 8:31 ` Yibo Zhao
2019-09-24 8:31 ` Yibo Zhao
2019-09-24 8:44 ` Toke Høiland-Jørgensen
2019-09-24 8:44 ` Toke Høiland-Jørgensen
2019-09-16 13:09 ` [PATCH 3/4] mac80211: fix low throughput in push pull mode Yibo Zhao
2019-09-16 13:09 ` Yibo Zhao
2019-09-16 15:27 ` Johannes Berg
2019-09-16 15:27 ` Johannes Berg
2019-09-17 6:36 ` Yibo Zhao
2019-09-17 6:36 ` Yibo Zhao
2019-09-17 6:55 ` Johannes Berg
2019-09-17 6:55 ` Johannes Berg
2019-09-17 21:12 ` Toke Høiland-Jørgensen
2019-09-17 21:12 ` Toke Høiland-Jørgensen
2019-09-18 10:02 ` Yibo Zhao
2019-09-18 10:02 ` Yibo Zhao
2019-09-18 10:16 ` Toke Høiland-Jørgensen
2019-09-18 10:16 ` Toke Høiland-Jørgensen
2019-09-18 10:18 ` Yibo Zhao
2019-09-18 10:18 ` Yibo Zhao
2019-09-16 13:09 ` [PATCH 4/4] mac80211: Sync airtime weight sum with per AC synced sta airtime weight together Yibo Zhao
2019-09-16 13:09 ` Yibo Zhao
2019-09-17 21:24 ` Toke Høiland-Jørgensen
2019-09-17 21:24 ` Toke Høiland-Jørgensen
2019-09-18 10:16 ` Yibo Zhao
2019-09-18 10:16 ` Yibo Zhao
2019-09-16 14:51 ` [PATCH 1/4] mac80211: Switch to a virtual time-based airtime scheduler Toke Høiland-Jørgensen
2019-09-16 14:51 ` Toke Høiland-Jørgensen
2019-09-17 21:31 ` Toke Høiland-Jørgensen
2019-09-17 21:31 ` Toke Høiland-Jørgensen
2019-09-20 8:37 ` Yibo Zhao
2019-09-20 8:37 ` Yibo Zhao
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r24640kb.fsf@toke.dk \
--to=toke@redhat.com \
--cc=ath10k@lists.infradead.org \
--cc=linux-wireless-owner@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=yiboz@codeaurora.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.