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 05B7A3B2A4 for ; Thu, 13 Sep 2018 00:10:32 -0400 (EDT) Received: by mail-lj1-x241.google.com with SMTP id j19-v6so3432519ljc.7 for ; Wed, 12 Sep 2018 21:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1rsx0IHn7DnUNsJBBUlqbnNx8s22nqvMAAlJ31QCQEs=; b=bPaypwFtRG4prTJ2ENBMjT4ocI9h2bfAEJd0xuq6HGaKVBo9NZvBVJ3mtl/FsSJYZe q/PwZiS1r8ARm7bHe/NR9/UXLADpzu7VQ1Xi1p0yFCvicQroAqzl0hVfze24xvKcqJau T75lYMbNpXfgJIr1IBfQhHFdaSg0K4r4kpfWclgqoecZoneK0747XhHXdktWuMmZstrH qQ+Uoy/XDJXUCCNkrRlxqcFzN1r6PEZfq4KXwMb80nQg7lQ57ySzhsAJJpdWhmJaaHax fdV7gUKuE9jVOlKY+Cv7k7yyyVkHCv2sqeQYP88Gtm786l+6pxTNK5qgfRNdGV8UySnI lC2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1rsx0IHn7DnUNsJBBUlqbnNx8s22nqvMAAlJ31QCQEs=; b=BRwPRKKIT6SzhLSPh3rce1seW2r0gUgXVikfYfiZsAQDy4oxnbTz6x5SOgbE86ZBG+ ZCQ19zAbw135p0l33ikDZdlS7cPTpDvpWzX3BO+f2ArTlZmHT1Y49XqCNCAQVGxdii1Y ofa6lWgAStCiNNnawgYboc4I8iKgqgglZLDJfbIl3jjOkGj1Aoi8ZcMD44jA196wSMom HFHAehXtvNljqYvGapcBNzWcCrxMFGsMmNiJUqa7pHzsgpC4rpevRA0o/d1HWNAhA90G T+RIZsQQ1L+T8svRsvQHz+VXCoRw1ethNO4h4g1vwooCKh2YMu6dBzwQ6KYVBkc5nxzO S/dw== X-Gm-Message-State: APzg51DFmIxUecHvU/S05AHq8fHCTKP5dMQKrG26ErzeQ6qCXSNQHwFd Op2Y5Jf09ZeT0XqiutmM9a+HeY9HbLmY0uh/4UiIQw== X-Google-Smtp-Source: ANB0VdZg2pqV6/LcdXJv1c+sY6CN0+PlXv/iist+NOGitto/a+23aHghRLaBdtZtSpUiL4u7c47O6qB50nDQygLFElk= X-Received: by 2002:a2e:b007:: with SMTP id y7-v6mr3055060ljk.22.1536811831545; Wed, 12 Sep 2018 21:10:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:6504:c2:0:0:0:0 with HTTP; Wed, 12 Sep 2018 21:10:30 -0700 (PDT) In-Reply-To: <1536578789.3224.69.camel@sipsolutions.net> References: <153635803319.14170.10011969968767927187.stgit@alrua-x1> <1536565926.3224.15.camel@sipsolutions.net> <878t49lhy8.fsf@toke.dk> <1536578789.3224.69.camel@sipsolutions.net> From: Kan Yan Date: Wed, 12 Sep 2018 21:10:30 -0700 Message-ID: To: Johannes Berg Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , linux-wireless@vger.kernel.org, make-wifi-fast@lists.bufferbloat.net, Rajkumar Manoharan , Felix Fietkau Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [PATCH RFC v3 0/4] Move TXQ scheduling into mac80211 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, 13 Sep 2018 04:10:33 -0000 > I think this is a great approach, that we should definitely adopt in > mac80211. However, I'm not sure the outstanding airtime limiting should > be integrated into the fairness scheduling, since there are drivers such > as ath9k that don't need it. > > Rather, I'd propose that we figure out the API for fairness scheduling > first, and add the BQL-like limiter as a separate layer. They can be > integrated in the sense that the limiter's estimate of airtime can be > used for fairness scheduling as well in the case where the > driver/firmware doesn't have a better source of airtime usage. > > Does that make sense? Sure that make sense. Yes, the airtime based BQL like queue limiter is not needed for drivers such as ath9k. We could leave the outstanding airtime accounting and queue depth limit to another subject and get airtime fairness scheduling API done first. On Mon, Sep 10, 2018 at 4:26 AM, Johannes Berg wrote: > On Mon, 2018-09-10 at 13:17 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wrote= : > >> > > - I did not add any locking around next_txq(); the driver is still s= upposed >> > > to maintain a lock that prevents two threads from trying to schedu= le the >> > > same AC at the same time. This is what drivers already do, so I fi= gured it >> > > was easier to just keep it that way rather than do it in mac80211. >> > >> > I'll look at this in the code, but from a maintainer perspective I'm >> > somewhat worried that this will lead to issues that are really the >> > driver's fault, but surface in mac80211. I don't know how easy it >> > would be to catch that. >> >> Yeah, I get what you mean. The alternative would be to have a >> ieee80211_start_schedule(ac) and ieee80211_end_schedule(ac), which >> basically just takes a lock. > > And I guess start would increment the schedule number, which is now > dependent on first > >> Would mean we could get rid of the 'first' >> parameter for next_txq(), so might not be such a bad idea; > > Right, that's what I meant. > >> and if the >> driver has its own locking the extra locking in mac80211 would just be >> an always-uncontested spinlock, which shouldn't be much overhead, right? > > It may still bounce around CPUs if you call this from other places, but > I suspect that wouldn't be the biggest issue. There are a lot of > calculations going on too... > > johannes