From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id F22453CB35 for ; Thu, 17 Oct 2019 21:11:41 -0400 (EDT) Received: by mail-lj1-x241.google.com with SMTP id v24so4465923ljj.3 for ; Thu, 17 Oct 2019 18:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QC1w77VZRCYH8hERen99ZGhUOT4e8Ag48k7m9duGNJo=; b=piwlDLGZJ2Cjg5TDHivlsZpECNNmqLdCMmpZe1A4OcvQGqGztVVdfZIoEsk2tzKBgG cqN1SN9tDlPEInQP+Wg+3bioBjX81z7HujES5bQqRNbJRlhpOAfYRmINYj2JZBy4BoZb lkB14g86Hlt2Egqoxtt6boWW2eC8CM2mM/t3dHyV2Mi4fxkKV8KZBS0qi6XN13Ao7KMQ NqXNHLBPSeGSfsGT1m7+lMWCnjKej/rZFZrBcR7TjHqvWhdhQIhsgssTGFlmp6E9Mms6 9mMTeWdc8HUzKJDFeuQzaedaCXEOq8uyjevAz24XCkzhPN38yhCzDu7OCe3jGIx9GQU4 DAzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QC1w77VZRCYH8hERen99ZGhUOT4e8Ag48k7m9duGNJo=; b=tjwFpy0SaH69taU8U7bpKZ3nmeuPXHPRHxyoOzPe6pHjN5ol0PYCIKyM6lNc3CJ9rl e4hpcHW3r7FvsDhXb+sH3II1qUoS5fBaSBzz4KF48Lgw5+IrYhV0Y0GO/8XXpR8GFb+Q oowMw4+EPo6WXd0Six0S6D7zHZi536iundDhRKrlG7ioIcQDD9qZgXfS17byII9+zXOW Shz6e31xKhJLl7PKvo8aB8Lfzh3o7muX/tMATGwtXHlokZDf2AiT1lAyJjpfAPpDWDdH gxO0MIqa5mSPg+KFc6R4KqjR1OH8H0scSQK7pEzFI+eUwVG1o4S4yG6eiqeP1QXikl1f lrmg== X-Gm-Message-State: APjAAAX8JEoJPe70W2nuJ+EogfE6TVsj27zy9NNZ9OVrdeWWg4rQ11bS uvRimE/gClMq3jDR5FiQFoSwmZBrhNVBd/m+abfofQ== X-Google-Smtp-Source: APXvYqxckgV4ZGs3rGfnunRJYCJMzCOaIPPUPpsiIF3aa1tlLcfzaUqCsmN9gDIs18anyfHar+FxQrohUwR2xwC3gn0= X-Received: by 2002:a05:651c:112e:: with SMTP id e14mr4200386ljo.193.1571361100416; Thu, 17 Oct 2019 18:11:40 -0700 (PDT) MIME-Version: 1.0 References: <157115993755.2500430.12214017471129215800.stgit@toke.dk> <157115994190.2500430.14955682016008497593.stgit@toke.dk> <87o8yfg0zo.fsf@toke.dk> <751EA059-654B-4E06-A3D6-C727FE1FCE98@gmx.de> <87lftjfz51.fsf@toke.dk> <18FC6F1D-084C-44BD-87E7-C9F394D6FCD1@gmx.de> In-Reply-To: <18FC6F1D-084C-44BD-87E7-C9F394D6FCD1@gmx.de> From: Kan Yan Date: Thu, 17 Oct 2019 18:11:29 -0700 Message-ID: To: Sebastian Moeller Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Rajkumar Manoharan , Kevin Hayes , Make-Wifi-fast , linux-wireless@vger.kernel.org, ath10k@lists.infradead.org, John Crispin , Johannes Berg , Lorenzo Bianconi , Felix Fietkau Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [PATCH v2 4/4] mac80211: Use Airtime-based Queue Limits (AQL) on packet dequeue 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 01:11:42 -0000 I don't think it is hard to take care of extra header size for frames with VLAN tags, but the question is how far are we willing to go down this rabbit hole. There are other factors like retries and aggregation that are difficult to be taken into account. However, I doubt that matters, a ballpark estimate of airtime is sufficient for the purpose of implementing a queue limit. On Thu, Oct 17, 2019 at 3:25 AM Sebastian Moeller wrote: > > What about VLAN tags? > > Best Regards > Sebastian > > > On Oct 17, 2019, at 12:24, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > > > Sebastian Moeller writes: > > > >>> On Oct 17, 2019, at 11:44, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > >>> > >>> Kan Yan writes: > >>> > >>>> Hi Toke, > >>>> > >>>> Thanks for getting this done! I will give it a try in the next few > >>>> days. A few comments: > >>>> > >>>>> The estimated airtime for each skb is stored in the tx_info, so we = can > >>>>> subtract the same amount from the running total when the skb is fre= ed or > >>>>> recycled. > >>>> > >>>> Looks like ath10k driver zero out the info->status before calling > >>>> ieee80211_tx_status(...): > >>>> int ath10k_txrx_tx_unref(struct ath10k_htt *htt, > >>>> const struct htt_tx_done *tx_done) > >>>> { > >>>> ... > >>>> info =3D IEEE80211_SKB_CB(msdu); > >>>> memset(&info->status, 0, sizeof(info->status)); > >>>> ... > >>>> ieee80211_tx_status(htt->ar->hw, msdu); > >>>> } > >>> > >>> Ah, bugger; I was afraid we'd run into this. A quick grep indicates t= hat > >>> it's only ath10k and iwl that do this, though, so it's probably > >>> manageable to just fix this. I think the simplest solution is just to > >>> restore the field after clearing, no? > >>> > >>>> We need either restore the info->status.tx_time_est or calling > >>>> ieee80211_sta_update_pending_airtime() in ath10k before tx_time_est > >>>> get erased. > >>>> > >>>>> + if (local->airtime_flags & AIRTIME_USE_AQL) { > >>>>> + airtime =3D ieee80211_calc_expected_tx_airtime(hw, = vif, txq->sta, > >>>>> + skb->l= en + 38); > >>>> > >>>> I think it is better to put the "+ 38" that takes care of the heade= r > >>>> overhead inside ieee80211_calc_expected_tx_airtime(). > >>> > >>> Hmm, no strong opinion about this; but yeah, since we have a dedicate= d > >>> function for this use I guess there's no harm in adding it there :) > >>> > >> > >> Silly question, is this Overhead guaranteed to be 38 Bytes for all > >> eternity? Otherwise a variable or a preprocessor constant might be > >> more future proof? > > > > Well, yeah, as long as we're sending Ethernet packets. Which is kinda > > baked into the WiFi standard :) > > > > -Toke >