From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 464163B2A4 for ; Fri, 18 Oct 2019 08:21:57 -0400 (EDT) Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.92.2) (envelope-from ) id 1iLRGT-00023f-Lb; Fri, 18 Oct 2019 14:21:53 +0200 Message-ID: <10b885b3238cede2d99c6134bebcc0c8ba6f6b10.camel@sipsolutions.net> From: Johannes Berg To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , Kan Yan Cc: linux-wireless@vger.kernel.org, make-wifi-fast@lists.bufferbloat.net, ath10k@lists.infradead.org, John Crispin , Lorenzo Bianconi , Felix Fietkau , Rajkumar Manoharan , Kevin Hayes Date: Fri, 18 Oct 2019 14:21:52 +0200 In-Reply-To: <87sgnqe4wg.fsf@toke.dk> References: <157115993755.2500430.12214017471129215800.stgit@toke.dk> <157115993866.2500430.13989567853855880476.stgit@toke.dk> <87sgnqe4wg.fsf@toke.dk> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [Make-wifi-fast] [PATCH v2 1/4] mac80211: Rearrange ieee80211_tx_info to make room for tx_time_est X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 12:21:57 -0000 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