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 A5A713CB35 for ; Mon, 10 Sep 2018 09:11:03 -0400 (EDT) Received: by sipsolutions.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1fzLy0-0006A9-Ha; Mon, 10 Sep 2018 15:11:00 +0200 Message-ID: <1536585051.3224.72.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 15:10:51 +0200 In-Reply-To: <87wortjy8n.fsf@toke.dk> References: <153635803319.14170.10011969968767927187.stgit@alrua-x1> <153635897010.14170.2992498632345986102.stgit@alrua-x1> <1536565717.3224.12.camel@sipsolutions.net> <87musplivy.fsf@toke.dk> <1536577419.3224.50.camel@sipsolutions.net> <87zhwpjzme.fsf@toke.dk> <1536583587.3224.71.camel@sipsolutions.net> <87wortjy8n.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 1/4] mac80211: Add TXQ scheduling API 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 13:11:03 -0000 On Mon, 2018-09-10 at 15:08 +0200, Toke Høiland-Jørgensen wrote: > Johannes Berg writes: > > > On Mon, 2018-09-10 at 14:39 +0200, Toke Høiland-Jørgensen wrote: > > > > > > From then on, right now we basically just try to refill the hardware > > > > queue from the TXQ whenever the hardware releases frames from that > > > > queue. If there are none, we fall back to putting them on the hardware > > > > queue from the wake signal. > > > > > > OK. So if the TXQ is ineligible to dequeue packets, but still have them > > > queued, there would need to be a signal (such as wake_txq()) when it > > > becomes eligible again, right? > > > > Right. It wouldn't have to be wake_txq, but that seems as appropriate as > > anything else. > > > > If we were to use ieee80211_airtime_may_transmit(), we'd have to have > > something that tells us "I previously told you it may not transmit, but > > now I changed my mind" :-) > > Yes, exactly. Hmm, I'll see what I can come up with :) No need to look at this right now - let's get this stuff sorted out first :) johannes