From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B51E73B2A4 for ; Thu, 13 Sep 2018 05:25:25 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1536830724; bh=7ePFXKGJ1jxQ1JCDCLQuOo8sTcDJ2xJQrKW0Zocz0mw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ceaIasgeDwsPOwGOPbB2DLEVyC7D2j8hkiVOyh9gWSuUJ3dc2cn/jJP+Zl2JVYep7 lDdVSEweX2kWRPPK+bA/Fo/QeKQN2jnoj9vIdlosfKBPNM3bu1CG071CzMATmNvT4G j7VSRJO+/Wc1zP905T8T8bY+g0rr/NDCN4g5yeRWUxrJsGenYvF/xs75OZw/JOpcKc lW3CgkrtlzglaRyuJYsrPg69AUyEeWXZCe1dmvfq2udxO/iuP08mGLFy8+mvhLRfIj fNNleyK0PdNeu5MEtj+Qak6HdiWpFtaziVgWnXZW62lPxnhZtFC0EKB1Dk0tCvvf52 TvZEQ7TlUhBfA== To: Kan Yan , Johannes Berg Cc: linux-wireless@vger.kernel.org, make-wifi-fast@lists.bufferbloat.net, Rajkumar Manoharan , Felix Fietkau In-Reply-To: References: <153635803319.14170.10011969968767927187.stgit@alrua-x1> <1536565926.3224.15.camel@sipsolutions.net> <878t49lhy8.fsf@toke.dk> <1536578789.3224.69.camel@sipsolutions.net> Date: Thu, 13 Sep 2018 11:25:23 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87y3c5hhq4.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain 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 09:25:25 -0000 Kan Yan writes: >> 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. Cool! I was thinking I would stub out an untested PoC in a separate patch on my next submission, to show how I think this could be incorporated. Have some other stuff to finish up this week, but hopefully I'll have time to do the next version over the weekend :) -Toke