From: Johannes Berg <johannes@sipsolutions.net>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>, "Kan Yan" <kyan@google.com>
Cc: linux-wireless@vger.kernel.org,
make-wifi-fast@lists.bufferbloat.net, ath10k@lists.infradead.org,
John Crispin <john@phrozen.org>,
Lorenzo Bianconi <lorenzo@kernel.org>,
Felix Fietkau <nbd@nbd.name>,
Rajkumar Manoharan <rmanohar@codeaurora.org>,
Kevin Hayes <kevinhayes@google.com>
Subject: Re: [PATCH v2 1/4] mac80211: Rearrange ieee80211_tx_info to make room for tx_time_est
Date: Fri, 18 Oct 2019 15:48:13 +0200 [thread overview]
Message-ID: <9fc60b546b54b40357264d67536733251cf39ebe.camel@sipsolutions.net> (raw)
In-Reply-To: <87imomdvsj.fsf@toke.dk>
On Fri, 2019-10-18 at 15:31 +0200, Toke Høiland-Jørgensen wrote:
> Well, let's try to do the actual math... A full-size (1538 bytes) packet
> takes ~2050 microseconds to transmit at 6 Mbps. Adding in overhead, it's
> certainly still less that 4096 us, so 12 bits is plenty.
What about A-MSDUs? But I guess maximum continous transmissions are at
most 4ms anyway, so a single packet should never be longer.
> That leaves
> four bits for the ACK status ID if we just split the u16; if we only
> ever have "a handful", that should be enough, no?
It's how many are in flight at a time, 16 doesn't seem likely to happen,
but I don't really know what applications are doing with it now.
Probably only wpa_s for the EAPOL TX status.
> We could also split 5/11. That would support up to 32 ACK IDs, and we
> can just truncate the airtime at 2048 us, which is not a big deal I'd
> say.
We can also play with the units of the airtime, e.g. making that a
multiple of 2 or 4 us? Seems unlikely to matter much?
> Think it mostly depends on what is the smallest ID space for ACK IDs we
> can live with? :)
:)
TBH, I don't really know. In a lot of hardware using this is really bad
for performance so it shouldn't be used much, so ...
johannes
WARNING: multiple messages have this Message-ID (diff)
From: Johannes Berg <johannes@sipsolutions.net>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>, "Kan Yan" <kyan@google.com>
Cc: Rajkumar Manoharan <rmanohar@codeaurora.org>,
Kevin Hayes <kevinhayes@google.com>,
make-wifi-fast@lists.bufferbloat.net,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org,
John Crispin <john@phrozen.org>,
Lorenzo Bianconi <lorenzo@kernel.org>,
Felix Fietkau <nbd@nbd.name>
Subject: Re: [PATCH v2 1/4] mac80211: Rearrange ieee80211_tx_info to make room for tx_time_est
Date: Fri, 18 Oct 2019 15:48:13 +0200 [thread overview]
Message-ID: <9fc60b546b54b40357264d67536733251cf39ebe.camel@sipsolutions.net> (raw)
In-Reply-To: <87imomdvsj.fsf@toke.dk>
On Fri, 2019-10-18 at 15:31 +0200, Toke Høiland-Jørgensen wrote:
> Well, let's try to do the actual math... A full-size (1538 bytes) packet
> takes ~2050 microseconds to transmit at 6 Mbps. Adding in overhead, it's
> certainly still less that 4096 us, so 12 bits is plenty.
What about A-MSDUs? But I guess maximum continous transmissions are at
most 4ms anyway, so a single packet should never be longer.
> That leaves
> four bits for the ACK status ID if we just split the u16; if we only
> ever have "a handful", that should be enough, no?
It's how many are in flight at a time, 16 doesn't seem likely to happen,
but I don't really know what applications are doing with it now.
Probably only wpa_s for the EAPOL TX status.
> We could also split 5/11. That would support up to 32 ACK IDs, and we
> can just truncate the airtime at 2048 us, which is not a big deal I'd
> say.
We can also play with the units of the airtime, e.g. making that a
multiple of 2 or 4 us? Seems unlikely to matter much?
> Think it mostly depends on what is the smallest ID space for ACK IDs we
> can live with? :)
:)
TBH, I don't really know. In a lot of hardware using this is really bad
for performance so it shouldn't be used much, so ...
johannes
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2019-10-18 13:48 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-15 17:18 [PATCH v2 0/4] Add Airtime Queue Limits (AQL) to mac80211 Toke Høiland-Jørgensen
2019-10-15 17:18 ` Toke Høiland-Jørgensen
2019-10-15 17:18 ` [PATCH v2 1/4] mac80211: Rearrange ieee80211_tx_info to make room for tx_time_est Toke Høiland-Jørgensen
2019-10-15 17:18 ` Toke Høiland-Jørgensen
2019-10-18 0:50 ` Kan Yan
2019-10-18 0:50 ` Kan Yan
2019-10-18 10:15 ` Toke Høiland-Jørgensen
2019-10-18 10:15 ` Toke Høiland-Jørgensen
2019-10-18 12:21 ` Johannes Berg
2019-10-18 12:21 ` Johannes Berg
2019-10-18 13:31 ` Toke Høiland-Jørgensen
2019-10-18 13:31 ` Toke Høiland-Jørgensen
2019-10-18 13:48 ` Johannes Berg [this message]
2019-10-18 13:48 ` Johannes Berg
2019-10-18 14:01 ` Toke Høiland-Jørgensen
2019-10-18 14:01 ` Toke Høiland-Jørgensen
2019-10-18 14:07 ` Johannes Berg
2019-10-18 14:07 ` Johannes Berg
2019-10-18 14:22 ` Toke Høiland-Jørgensen
2019-10-18 14:22 ` Toke Høiland-Jørgensen
2019-10-18 14:14 ` Johannes Berg
2019-10-18 14:14 ` Johannes Berg
2019-10-18 14:30 ` Toke Høiland-Jørgensen
2019-10-18 14:30 ` Toke Høiland-Jørgensen
2019-10-18 12:35 ` Johannes Berg
2019-10-18 12:35 ` Johannes Berg
2019-10-18 13:01 ` Ben Greear
2019-10-18 13:01 ` Ben Greear
2019-10-15 17:18 ` [PATCH v2 2/4] mac80211: Import airtime calculation code from mt76 Toke Høiland-Jørgensen
2019-10-15 17:18 ` Toke Høiland-Jørgensen
2019-10-15 17:19 ` [PATCH v2 3/4] mac80211: Implement Airtime-based Queue Limit (AQL) Toke Høiland-Jørgensen
2019-10-15 17:19 ` Toke Høiland-Jørgensen
2019-10-15 17:19 ` [PATCH v2 4/4] mac80211: Use Airtime-based Queue Limits (AQL) on packet dequeue Toke Høiland-Jørgensen
2019-10-15 17:19 ` Toke Høiland-Jørgensen
2019-10-17 0:33 ` Kan Yan
2019-10-17 0:33 ` Kan Yan
2019-10-17 9:44 ` Toke Høiland-Jørgensen
2019-10-17 9:44 ` Toke Høiland-Jørgensen
2019-10-17 9:57 ` [Make-wifi-fast] " Sebastian Moeller
2019-10-17 9:57 ` Sebastian Moeller
2019-10-17 10:24 ` Toke Høiland-Jørgensen
2019-10-17 10:24 ` Toke Høiland-Jørgensen
2019-10-17 10:25 ` Sebastian Moeller
2019-10-17 10:25 ` Sebastian Moeller
2019-10-18 1:11 ` Kan Yan
2019-10-18 1:11 ` Kan Yan
2019-10-18 14:15 ` Johannes Berg
2019-10-18 14:15 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9fc60b546b54b40357264d67536733251cf39ebe.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=ath10k@lists.infradead.org \
--cc=john@phrozen.org \
--cc=kevinhayes@google.com \
--cc=kyan@google.com \
--cc=linux-wireless@vger.kernel.org \
--cc=lorenzo@kernel.org \
--cc=make-wifi-fast@lists.bufferbloat.net \
--cc=nbd@nbd.name \
--cc=rmanohar@codeaurora.org \
--cc=toke@redhat.com \
/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.