From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B110F3B29E for ; Mon, 10 Sep 2018 07:26:38 -0400 (EDT) Received: by sipsolutions.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1fzKKz-0004Qp-96; Mon, 10 Sep 2018 13:26:37 +0200 Message-ID: <1536578789.3224.69.camel@sipsolutions.net> From: Johannes Berg To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , linux-wireless@vger.kernel.org, make-wifi-fast@lists.bufferbloat.net Cc: Rajkumar Manoharan , Felix Fietkau Date: Mon, 10 Sep 2018 13:26:29 +0200 In-Reply-To: <878t49lhy8.fsf@toke.dk> References: <153635803319.14170.10011969968767927187.stgit@alrua-x1> <1536565926.3224.15.camel@sipsolutions.net> <878t49lhy8.fsf@toke.dk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 (3.26.6-1.fc27) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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:26:38 -0000 On Mon, 2018-09-10 at 13:17 +0200, Toke Høiland-Jørgensen wrote: > > > - I did not add any locking around next_txq(); the driver is still supposed > > > to maintain a lock that prevents two threads from trying to schedule the > > > same AC at the same time. This is what drivers already do, so I figured 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