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 2D6E13B29D for ; Thu, 27 Feb 2020 06:08:00 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582801679; 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=bR8yx4+VHxBq4L4tV6VbkYwJF0ukCwDF5ztmto9ZSJg=; b=EgeoeLUFW/yhEHNDWHBbRPxQRi6pdvZZ+lKF/Z1Pw858w/1Q0EDfJvV1MqKeliuyZGGX+3 qENnk4rgB63xeg7Q858l6KFG6b2/oJrcIZBZ9dWeytsxURHOoNGkjayjfdGDYP2srzD4aE E4d/7D56826FSmtr7x/0BlWVF1E9hO0= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-57-Oj_BQ7FIMJGDo8ullxO0Fg-1; Thu, 27 Feb 2020 06:07:56 -0500 X-MC-Unique: Oj_BQ7FIMJGDo8ullxO0Fg-1 Received: by mail-wr1-f70.google.com with SMTP id y28so1139256wrd.23 for ; Thu, 27 Feb 2020 03:07:55 -0800 (PST) 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=bR8yx4+VHxBq4L4tV6VbkYwJF0ukCwDF5ztmto9ZSJg=; b=gtyrAecsFnkf027/bBP0OVe7/ia3D26oFkmcjB3pH1M5GRO+UTMwseguuXcgAvsMjR 5J3OzyPgyh0snLQiv0ESGP1uMKsaSRAnKzff2UE2rUSvfY2nlviETkdItvB8dygep+el rBI8vF3x4OzJqGsKbgixJOGsdgJD5lvfw1/Q4i/51QfoSiAxgauQM1pRFOz0rgNTAB0S 1dPHHBkcUKBMC51Lh1CHpxxw9d24TE3UIsgG2cPDj4qFFDFgsuq4NyKSY18pBlxOhINk GnIg054vstRuUFtQsCMzQs1mczAEDm/truD5NLIEt6lW7jgWGUN+xWQiHr7VIwLkKj8B TTnA== X-Gm-Message-State: APjAAAXuY3OU3h10KhX3nVb+4MRQF7FyCsdX743dm/oA27w0LSI7oPxV WErHHV/9g7C1svFKUpW7NrTbvfoWzk028HnuCPvbTT5G40WBdvC+OMabIp94I/11Q7zrDrLnSew o+BIyQp/Hub5f1k6ibZR1AksFPin9D0yqeMs= X-Received: by 2002:a05:600c:228f:: with SMTP id 15mr4898349wmf.56.1582801675084; Thu, 27 Feb 2020 03:07:55 -0800 (PST) X-Google-Smtp-Source: APXvYqxS8/QHS53GhPVQqHMpjggmy9YBMte88hrxHe1c+bQZYjVxXsno6nwIiPQ2XWQk6pzEZQ3fHw== X-Received: by 2002:a05:600c:228f:: with SMTP id 15mr4898323wmf.56.1582801674826; Thu, 27 Feb 2020 03:07:54 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk ([2a0c:4d80:42:443::2]) by smtp.gmail.com with ESMTPSA id h71sm8218971wme.26.2020.02.27.03.07.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Feb 2020 03:07:54 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id AC5CA180362; Thu, 27 Feb 2020 12:07:53 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Felix Fietkau , Kan Yan Cc: Johannes Berg , linux-wireless , Make-Wifi-fast , Yibo Zhao , John Crispin , Lorenzo Bianconi , Rajkumar Manoharan , Kevin Hayes In-Reply-To: References: <20191119060610.76681-1-kyan@google.com> <20191119060610.76681-5-kyan@google.com> <789d592c-5b1b-b785-6d9c-86b7cc7d57f4@nbd.name> <87k149xbb4.fsf@toke.dk> X-Clacks-Overhead: GNU Terry Pratchett Date: Thu, 27 Feb 2020 12:07:53 +0100 Message-ID: <87o8tkwanq.fsf@toke.dk> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [PATCH v11 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: Thu, 27 Feb 2020 11:08:00 -0000 Felix Fietkau writes: >> Not sure I fully understand your concerns here. The AQL budget is per >> STA, per TID, so frames queued in the driver's special queue for one >> station won't impact another station's budget. Those frames are >> counted towards the per interface pending airtime, which could trigger >> AQL to switch to use the lower queue limit. In this case, that could >> be the desirable behavior when there is heavy traffic. > Yes, the per interface limit is what I'm concerned about. I'm not sure > if it will be an issue in practice, it's just something that I noticed > while reviewing the code. Ah, right. Note that it's not a hard limit, though; it's just a threshold for when the per-station limit switches to a smaller value. The idea is that when there are many stations with outstanding data, each station's latency will be higher since they have to also wait for their turn to transmit. And so we compensate for this by lowering each station's queue limit, since the hardware is unlikely to become idle when there are many stations to send to. The lower limit is still 5ms of data, though, so there should still be enough for a full aggregate queued for each station. Arguably the limit could actually be made *smaller*: On a very busy network with lots of stations transmitting at once, IMO we *don't* want to send full-sized aggregates as that will add up to way too much latency. Better to sacrifice a bit of network efficiency to raise responsiveness :) -Toke