Re: [PATCH v2 1/4] mac80211: Rearrange ieee80211_tx_info to make room for tx_time_est

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