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 14:21:52 +0200	[thread overview]
Message-ID: <10b885b3238cede2d99c6134bebcc0c8ba6f6b10.camel@sipsolutions.net> (raw)
In-Reply-To: <87sgnqe4wg.fsf@toke.dk>

On Fri, 2019-10-18 at 12:15 +0200, Toke Høiland-Jørgensen wrote:

> However, there's a nice juicy 'u16 ack_frame_id' at the start of
> ieee80211_tx_info. Could we potentially use that? We could use the top
> bit as a disambiguation flag; I think we're fine with 15 bits for the TX
> time itself (a single packet won't exceed 8ms or TX time), so if we can
> live with 15 bits of ACK frame ID space, that could be a way forward?

I was going to say that should work as we only ever have a handful of
ACK frame IDs, but ... you still need the airtime even for a frame that
userspace wants to know the ACK status of, no?

We could pull the ack_frame_id out-of-line using the skb extensions
framework, but I'm not sure we should allocate one of the possible 8
extension IDs for that either ...

What we really should do is convert all (relevant) drivers to use rate
tables instead of having all the rates in the TX info, then we'd get a
lot of space, but that's a lot of work ...

johannes