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 7BE383CB35 for ; Mon, 10 Sep 2018 09:08:58 -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=1536584937; bh=Xmj/xfBdjbi/AWirkWZbN1+A7uOXccuGqOGg86snUZw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nJSaeHNSr8AN0q1ge0uoxq/DqvxXYLfLjJTiKqN55tQgABEt7NGJzMUCuP7TYBozi 9Gwct4sS3kIdbuKWp9utlt2HhPTFlrDwDzkUG5xg8RaFilLUs6W99pvDf3Uub0SpN6 iBT05VByzWsF7cS6FLGfp9H6sIC16ASrNpE/SdIjqzrtq97ICtEEw9253nR1nVfmgh QlSfqPk+Fse4AHHaXXJwxNIxcRCn4cOSDV7x6SxGTyyctvmzal1ghG3vTY7E89veDf AOW8QQjXr4m7xZnm8hYbnmBIR607KwYX30hNgtnvbFsWPowh3zKHVNny+EECUWXUEm XElqF8jjQMZ4w== To: Johannes Berg , linux-wireless@vger.kernel.org, make-wifi-fast@lists.bufferbloat.net Cc: Rajkumar Manoharan , Felix Fietkau In-Reply-To: <1536583587.3224.71.camel@sipsolutions.net> 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> Date: Mon, 10 Sep 2018 15:08:56 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87wortjy8n.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 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:08:58 -0000 Johannes Berg writes: > On Mon, 2018-09-10 at 14:39 +0200, Toke H=C3=B8iland-J=C3=B8rgensen 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. >>=20 >> 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 :) -Toke