From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B13A73CB35 for ; Fri, 18 Oct 2019 06:15:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1571393718; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fPfdn1wJgZGqQXuVAEaKG2OM7BuZcbx3t0qWbYXPYIY=; b=esV4LkAUTDsyBs84ugGwwdGt8nhLn3xbUYDMTAZNdsCivjwPAUU66ku8Xp4GATSu63+yHT pmcg+WBWNmvpnkHe81zxNJ5IsuK6RkH5jRYDX0T2Kcbl4OmjpSqyin6V3ug/dH/uHSN8X0 p7Kmn6f2PIDvr36sWkN3cAil6N5szg8= Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-156-qSRZ3nWUNICaJ0uL53bJ1A-1; Fri, 18 Oct 2019 06:15:15 -0400 Received: by mail-lf1-f72.google.com with SMTP id o9so1176297lfd.7 for ; Fri, 18 Oct 2019 03:15:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=fPfdn1wJgZGqQXuVAEaKG2OM7BuZcbx3t0qWbYXPYIY=; b=HAwBXkQFEdFYpAlpt9tzZ3h7pRWNl9/2OlKKDyXs4TsuOd3zaNeNF4tiTUzOcCbOQh 9RTxS+kzMZQ3gX+z5zxAxU3kfCq0srpzPJ2x3/tawvRKEIbLrPrtSDgt/woJJbbRf0N2 bn+Eia80ou8bXY8uGDj9xZo+H3VgqnyR90+TZ83Xn/p5ayXtE4Rl3fmtJfWtQLEmq9Hq MTWM8M+r5B+Jz0vy+mGfMnmP67eAOFVlskubc6stD1cbO5RCrA84qKuzOpofj8vibGh0 /cF+FBRCe+HFHUB3QZHQ4z3fgYUc51p8IShaeX5We7r9YfyLu/W7JIlB+IszLnAkNM+f thxQ== X-Gm-Message-State: APjAAAUp/1impPP2pFkuKievcT1wx9NPIg/FT78S3pfuzD0Of1xmxPmM k3xJzcdc3OzMvJxu3LLN0YFASr6NEvFXiOUwxFnLzg92CO+NdLFafe83CPHeAEhxO29Y7CnHXGu ERU9HNmi5O5HAco2jaQ7z9N5o9N6OtrlyJno= X-Received: by 2002:a2e:501c:: with SMTP id e28mr5633711ljb.201.1571393714343; Fri, 18 Oct 2019 03:15:14 -0700 (PDT) X-Google-Smtp-Source: APXvYqzS9cqDMn8709PKQFYCsL6fEv1jTLkzhF66c6MpwtxFxNTvaB57PQEp+T6O/S1uC35uTMRvqw== X-Received: by 2002:a2e:501c:: with SMTP id e28mr5633684ljb.201.1571393713934; Fri, 18 Oct 2019 03:15:13 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk (borgediget.toke.dk. [85.204.121.218]) by smtp.gmail.com with ESMTPSA id v1sm2085763lfe.34.2019.10.18.03.15.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Oct 2019 03:15:12 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 000821804C9; Fri, 18 Oct 2019 12:15:11 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Kan Yan Cc: Johannes Berg , 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 In-Reply-To: References: <157115993755.2500430.12214017471129215800.stgit@toke.dk> <157115993866.2500430.13989567853855880476.stgit@toke.dk> X-Clacks-Overhead: GNU Terry Pratchett Date: Fri, 18 Oct 2019 12:15:11 +0200 Message-ID: <87sgnqe4wg.fsf@toke.dk> MIME-Version: 1.0 X-MC-Unique: qSRZ3nWUNICaJ0uL53bJ1A-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable 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 10:15:18 -0000 Kan Yan writes: > The "tx_time_est" field, shared by control and status, is not able to > survive until the skb returns to the mac80211 layer in some > architectures. The same space is defined as driver_data and some > wireless drivers use it for other purposes, as the cb in the sk_buff > is free to be used by any layer. > > In the case of ath10k, the tx_time_est get clobbered by > struct ath10k_skb_cb { > dma_addr_t paddr; > u8 flags; > u8 eid; > u16 msdu_id; > u16 airtime_est; > struct ieee80211_vif *vif; > struct ieee80211_txq *txq; > } __packed; Ah, bugger, of course the driver that actually needs this is using the full driver_data space :P > Do you think shrink driver_data by 2 bytes and use that space for > tx_time_est to make it persistent across mac80211 and wireless driver > layer an acceptable solution? Hmm, the driver_data field is defined as an array of pointers, so we can only shrink it in increments of sizeof(void *). I think it may be feasible to shrink it (as in, I don't think any drivers are actually using the full 40 bytes), but doing this in a way that will gain us a 2-byte space that is also usable in the case driver_data is *not* used (i.e., it needs be able to align with a field in .control and .status as well) would require some serious surgery of the whole ieee80211_tx_info... 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? Johannes, what do you think? -Toke