From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9F9CB3B29E for ; Mon, 10 Sep 2018 07:17:52 -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=1536578271; bh=/tGMayQ6UD6iHerVLCX5qxaRLMkl2NxWnEiyFgxSDLU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=KO3VC+NNfs8ZuTVcNnktH8Vm1CGbeBgHmr7AtkpPnu1MtsnKBoyX1Yg70yo3zoWXC mTSu/mmeF7K1P78SQYYw+qUg3KZtmBZiJY2x1csvGBc/j+FELf/R7kAiC/1/KfsD/r xjzjU7+z/t8R3wivcyaVDGqs0ed22lOqeUXtxZ455LYCFuc1L9BccelOHx9Mc2Gajc xHNpHSmBQd+krH2I1YvUH0CyihY+3B/YrEsOAhG4W+HfNG5vbjvT5gx4eHtG+4+LWu Mp33NvJyamCDvZ4y8DGqRX8Mq29Q8lMAX7FuxorX9t+3Ze/3C0l66D+r3BAjyEL2HH kPdMOnpTJMx3g== To: Johannes Berg , linux-wireless@vger.kernel.org, make-wifi-fast@lists.bufferbloat.net Cc: Rajkumar Manoharan , Felix Fietkau In-Reply-To: <1536565926.3224.15.camel@sipsolutions.net> References: <153635803319.14170.10011969968767927187.stgit@alrua-x1> <1536565926.3224.15.camel@sipsolutions.net> Date: Mon, 10 Sep 2018 13:17:51 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <878t49lhy8.fsf@toke.dk> MIME-Version: 1.0 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: Mon, 10 Sep 2018 11:17:52 -0000 Johannes Berg writes: > On Sat, 2018-09-08 at 00:22 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>=20 >> A few things that were discussed in the last round that I did *not* chan= ge: > > Thanks for this list btw. > >> - I did not add any locking around next_txq(); the driver is still suppo= sed >> to maintain a lock that prevents two threads from trying to schedule t= he >> same AC at the same time. This is what drivers already do, so I figure= d 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. Would mean we could get rid of the 'first' parameter for next_txq(), so might not be such a bad idea; 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? -Toke