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 C6DA93B29E for ; Wed, 22 Nov 2017 09:25:28 -0500 (EST) 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=1511360726; bh=7I2qndQSIS3xqESF1jqIRgMuEkf60oeoc807SDtlA3M=; h=From:To:Subject:In-Reply-To:References:Date:From; b=Q/IxA5zoZrxQa4kZIPJacVoa16Ab1lJVtbNn60P6IOf/ZmRKRZPexS/5BYlszcurD 9xGjvdZ/wgrVA6oD6p32pPH1VAokHx1TH1l/DWI7sdPcOnmHSzR5sLyEGyTALOyuSM D92zXeXe5XD3A69FZbH6U1T8XXST/gcdQQRk1HcucLUaLkr3bZUV/+y/sEQ/6a8w2+ Y+j4qhHcFTBLtgpYvBBGP6GYYASSAHRb9pCaBxSIvkzDwek2+Svfremwiask+ZE+gD 8/nGbPgwswNyLH8/doDBMwfZbp5vbmYCkc0AfAZlD598dbk8wcTDx/Y0gfmiXli/H9 8rcK08deQ/o2A== To: Louie Lu , Make-wifi-fast@lists.bufferbloat.net In-Reply-To: References: Date: Wed, 22 Nov 2017 15:25:24 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87vai28k6j.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Make-wifi-fast] How to figure out Linux wifi queue and ath10k queue scheduling? 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, 22 Nov 2017 14:25:29 -0000 Hi Louie > I'm working on making VoWIFI performance more better on ath10k driver, > my first thought is that I can modify queue scheduling algorithm > inside ath10k. Sounds awesome! What kind of VoIP traffic are you working with, and what aspect of performance are you looking to improve? :) > After tracking the commit log, it seems currently ath10k is using > mac80211 as an intermidieate queue[1][2], and as [2] indicate, ath10k > is not able to do airtime fairness now. Yup, that's about right. We're working on the airtime fairness part, though; see my recent presentation at Netdev a few weeks ago for an updated status on previous and ongoing work [1]. > After reading the source code and [2], what I think about the queue in > Linux to ath10k is: > > 1. Mac layer queue (mac80211) > 2. ath10k 802.11e priority queues (4 queues, with different 802.11e ToS level) > 3. ath10k firmware (HW) queue > > Am I right on this? More or less (I don't know enough about how ath10k works internally to tell you exactly how the internal queueing in the driver works). Ideally, the lower-level queues (2 and 3) should be as empty as possible, but no one ever got around to working on improving that. There was an aborted attempt to apply the dynamic queue limit code[2] to ath10k a while ago, but it was never completed. The WiP commit is here: [3]. > Also, I saw the make-wifi-fast google docs[3], it has a plan for > obsolete VO queue, is that still in the roadmap, or it is implemented, > if not, where can I help for it? The work on the different QoS levels has mostly been on the idea stage so far. My presentation[1] has some ideas related to this as well, but nothing has been implemented thus far. What's on the roadmap depends mostly on what people go ahead and implement ;) -Toke [1] https://www.netdevconf.org/2.2/session.html?jorgensen-wifistack-talk [2] https://lwn.net/Articles/454390/ [3] https://github.com/kazikcz/linux/commit/1486ffbafdb4dd433203c35c694b7443fa769210