From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f65.google.com (mail-ed1-f65.google.com [209.85.208.65]) (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 6AFE03CB35 for ; Thu, 7 Mar 2019 04:46:19 -0500 (EST) Received: by mail-ed1-f65.google.com with SMTP id f19so12851056eds.12 for ; Thu, 07 Mar 2019 01:46:19 -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:content-transfer-encoding; bh=BtfS1JxvO5l5x76oAhH/IioKddwHqs1WM3Ak4UG8Dsc=; b=EjhoWGoMFcNwoa34VOthBJ+sI4Y0+WqMTJ4Puu6PQknDK+Algf5+Wn+vTJEP0h9bY2 6caLRg/8HJ+e2vQRVeU5abua3xa9YNcET5NBe6rArcAJ5UUl/21AP6CAGEAU2ms2kjUw 4/e+SVXce15FMkBLOVONC/XR3sZAopDD8xmSjxvREvEX5iO99VOqD3RCnjtlePkyyxqx vaJFzkj5gdMKTbAym0u3zxZIW5H5bgkqxSv2nVumHaWf9MZf2w2QW4MWfLPbJwer1USJ a9mFO5o4M7fFCvh8tZQmWmlaq4S8m/QixBi+XPiRi5rq7big5h7Ow+xcL7gz256X9Q38 33Bg== X-Gm-Message-State: APjAAAV+2nG3FHguG3DpF8dsFqs2t8esSu22DtQNgLrpu5XThHeIGWEK eWOB29LKdP4AnRyc+VMazpIyPA== X-Google-Smtp-Source: APXvYqwHATPpAvubJGDzL0BAkCUHrZ8ZsSgPKqjkZCmnnmJ+Y3fnN1qAevFZtYYN3B3Eriqz4qzbsw== X-Received: by 2002:a17:906:3fd1:: with SMTP id k17mr7137803ejj.87.1551951978473; Thu, 07 Mar 2019 01:46:18 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk (borgediget.toke.dk. [85.204.121.218]) by smtp.gmail.com with ESMTPSA id t25sm790381ejr.30.2019.03.07.01.46.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 07 Mar 2019 01:46:17 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 6E886182F5B; Thu, 7 Mar 2019 10:46:17 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Rajkumar Manoharan Cc: make-wifi-fast@lists.bufferbloat.net, linux-wireless@vger.kernel.org, Felix Fietkau , Kan Yan , linux-wireless-owner@vger.kernel.org In-Reply-To: <69d22b9e3ea08a81fea8b8742cb697c5@codeaurora.org> References: <20190215170512.31512-1-toke@redhat.com> <87va0x1g0j.fsf@toke.dk> <69d22b9e3ea08a81fea8b8742cb697c5@codeaurora.org> X-Clacks-Overhead: GNU Terry Pratchett Date: Thu, 07 Mar 2019 10:46:17 +0100 Message-ID: <87wolbyq3a.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [RFC/RFT] mac80211: Switch to a virtual time-based airtime scheduler 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, 07 Mar 2019 09:46:19 -0000 Rajkumar Manoharan writes: > On 2019-03-05 07:45, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> Toke H=C3=B8iland-J=C3=B8rgensen writes: >>=20 >>> This switches the airtime scheduler in mac80211 to use a virtual=20 >>> time-based >>> scheduler instead of the round-robin scheduler used before. This has a >>> couple of advantages: >>>=20 >>> - No need to sync up the round-robin scheduler in firmware/hardware=20 >>> with >>> the round-robin airtime scheduler. >>>=20 >>> - If several stations are eligible for transmission we can schedule=20 >>> both of >>> them; no need to hard-block the scheduling rotation until the head=20 >>> of the >>> queue has used up its quantum. >>>=20 >>> - The check of whether a station is eligible for transmission becomes >>> simpler (in ieee80211_txq_may_transmit()). >>>=20 >>> The drawback is that scheduling becomes slightly more expensive, as we= =20 >>> need >>> to maintain an rbtree of TXQs sorted by virtual time. This means that >>> ieee80211_register_airtime() becomes O(logN) in the number of=20 >>> currently >>> scheduled TXQs. However, hopefully this number rarely grows too big=20 >>> (it's >>> only TXQs currently backlogged, not all associated stations), so it >>> shouldn't be too big of an issue. >>>=20 >>> Signed-off-by: Toke H=C3=B8iland-J=C3=B8rgensen >>> --- >>> This is basically the idea I mentioned earlier for a different way to >>> handle the airtime scheduling. >>>=20 >>> I've tested it on ath9k, where it achieves the same fairness and >>> weighing properties as the old scheduler. It would be good if you=20 >>> could >>> test it on your ath10k setup, Rajkumar; and all of you please comment=20 >>> on >>> whether you agree that this is better from an API point of view. >>=20 >> So no one has any comments on this? :) >>=20 > Toke, > > This is kind of design change. ;) Yup, that was kinda the point ;) > FMU w.r.t ath10k, earlier deficit adjustment and list rotation happens > at next_txq and may_transmit. Now it seems the rbtree adjustment > happens upon new txq insertion through wake_txq and whenever driver > reports airtime by register_airtime. Am I right? Yes. This change was, in part, motivated by the discussions we had around your patches to ath10k, and the need to make the round-robin schedulers sync up. I consider that a bit of a hack which this approach avoids. > We are using pretty old kernel (3.14, 4.4). It definitely needs backport= =20 > of rbtree. Well I wasn't necessarily planning for this to be backported. It doesn't change the driver API, and *in theory the aggregate fairness behaviour should be the same between the two scheduling approaches (famous last words). Verifying that this is actually the case is why I'm asking for testing. Also, isn't rbtree pretty old? A git blame on rbtree.c suggests it goes all the way back to the 2.6 era... > Have you used *Wrt image or validation on x86? I have only tested this on x86 with a mac80211-next-based kernel... -Toke