From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 05FFF3B2A4 for ; Wed, 25 Sep 2019 08:52:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1569415969; 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=RAxkE1h5ax6Fw7x83rQJVKg6nF9IOu73qh/OcRTyCUM=; b=F+zfV1c8egcko+3etDRG+FEehD7XhITistzT/7LcVc3OAXPaZumpwu8kpEIvzcM1r45x/S 6sAf7+lN0V5gLjdF7enO/1RNIZe2Fc7/r6lV4ZiGanGREPTX5THHFKD3r9/37mnARw2G/D BpCpQoOJvNz0uSfIDRlwkuANxgDly2U= Received: from mail-lf1-f69.google.com (mail-lf1-f69.google.com [209.85.167.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-73-jJC9diydONiIVZs1rVDasw-1; Wed, 25 Sep 2019 08:52:43 -0400 Received: by mail-lf1-f69.google.com with SMTP id m17so817433lfl.11 for ; Wed, 25 Sep 2019 05:52:42 -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:content-transfer-encoding; bh=RAxkE1h5ax6Fw7x83rQJVKg6nF9IOu73qh/OcRTyCUM=; b=AjCR10ws5eZy18r2cNJcPnG79uBUUE81f+Af9vN6Hs1jJxJQj5eotG4Sg0t5/N+dJ9 hSblEPttS09LNQFmIehhOS/wwz24zxUll2ni62Lm9udVIaRKuxr/d4mHvRwVhbAFeIlI ZP1zn6Q7ur+TbbcNJTWsVL5ItGy7Ur1j9RB1kY2wBo76eavq87Sj8ekDl6yffXPAM1QJ B4268uSxSXz37ibQbZYB5OoTweK5KWwmv8eBZ6gr4qXLnZMMpzJxEpVaOeHuZbQ6Ff9b sJmMQnh9D2Jgd8iXo3JFJBI2SOS7sxkzHIh0ZAR1v3X1pZUFZvOWwYIw17KTQQ56g4ax GyBA== X-Gm-Message-State: APjAAAUoyJ3cc4D4TFEd2QStYLC5qJ9+jzpd5mloaRAnxW6MvzDnZQ4X tpNUOij4gcB3qk7MP9ERBn3QOdByrBh2uVad/jhX8Cwv0zgmWhCAyhKTw4hqigbCVihWcaBJPIv 7qhtzHt8UZCmZ3bHogFV9Xp0yAZlIsnlcK0M= X-Received: by 2002:a2e:6e04:: with SMTP id j4mr5754585ljc.99.1569415961691; Wed, 25 Sep 2019 05:52:41 -0700 (PDT) X-Google-Smtp-Source: APXvYqzDu6srlULdJ6FcUoQhtVcUpzhekdTROR9PDW2pnqEP42W3cf8lyFlaLcAbuTgcVyv31wAOpw== X-Received: by 2002:a2e:6e04:: with SMTP id j4mr5754561ljc.99.1569415961476; Wed, 25 Sep 2019 05:52:41 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk (borgediget.toke.dk. [85.204.121.218]) by smtp.gmail.com with ESMTPSA id q66sm1181957ljq.101.2019.09.25.05.52.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Sep 2019 05:52:40 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 9D6A218063D; Wed, 25 Sep 2019 14:52:39 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Yibo Zhao Cc: Johannes Berg , linux-wireless@vger.kernel.org, make-wifi-fast@lists.bufferbloat.net, John Crispin , Lorenzo Bianconi , Felix Fietkau , linux-wireless-owner@vger.kernel.org In-Reply-To: <8c5a3a011f03d4dd4165b838a2b8bc72@codeaurora.org> References: <156889576422.191202.5906619710809654631.stgit@alrua-x1> <156889576869.191202.510507546538322707.stgit@alrua-x1> <2f6b649dcb788222e070ebb5593918c7@codeaurora.org> <87y2yc3ieb.fsf@toke.dk> <8c5a3a011f03d4dd4165b838a2b8bc72@codeaurora.org> X-Clacks-Overhead: GNU Terry Pratchett Date: Wed, 25 Sep 2019 14:52:39 +0200 Message-ID: <87mues35d4.fsf@toke.dk> MIME-Version: 1.0 X-MC-Unique: jJC9diydONiIVZs1rVDasw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [PATCH RFC/RFT 4/4] mac80211: Apply Airtime-based Queue Limit (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: Wed, 25 Sep 2019 12:52:50 -0000 Yibo Zhao writes: > On 2019-09-25 16:11, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> Yibo Zhao writes: >>=20 >>> So if it is going to work together with virtual time based mechanism=20 >>> in >>> the future, the Tx criteria will be met both of below conditions, >>> 1. Lower than g_vt >>> 2. Lower than IEEE80211_AIRTIME_QUEUE_LIMIT >>=20 >>> Are we going to maintain two kinds of airtime that one is from >>> estimation and the other is basically from FW reporting? >>=20 >> Yes, that was my plan. For devices that don't have FW reporting of >> airtime, we can fall back to the estimation; but if we do have FW >> reporting that is most likely going to be more accurate, so better to >> use that for fairness... > > Do you mean we will use airtime reported by FW to calculate=20 > local->airtime_queued in case we have FW reporting airtime? No, the opposite; if the firmware can't report airtime, we can use the estimated values to feed into report_airtime() for the fairness calculation... -Toke