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 500BD3BA8E for ; Wed, 29 Aug 2018 06:09:44 -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=1535537382; bh=S8vzJiR+AliQyZ4OXmCtvS+b8N9uyLkYrsg+OuJ3x5o=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hqpre9ddt0XbiDpHoz0++9Qshelb1sZDTxOGrqKyBw0+7kYdbtNq8nGwpPxQZAVAd 151tFF7Xb7oxcCxexf/Wt5t+bg1TvMB5JtFa2rwnVw5HKD5ImoiahnlyQ4sxzNdjMo 9P3qF5UNCD4jcn3UlFSsJ6wo+9rEMUf9L8Nchh86+WSl8PxmNTRUydLYldte2s2vBP lufu0tiZGvZm2fL5g/MEiAKKUYmG7mUfhjPx1WjLJAaomlzFngeGFR9MX52T5dlRIz 76w/BYn+guWtHmzAZ4syjYrvQWHf87w9yfmR0qa8JKMP2tt8Re3MVJajLUeyTLmNUF E5fBjOUvgw3Ww== To: Johannes Berg , linux-wireless@vger.kernel.org Cc: make-wifi-fast@lists.bufferbloat.net, Felix Fietkau In-Reply-To: <1535534678.5215.23.camel@sipsolutions.net> References: <153115421866.7447.6363834356268564403.stgit@alrua-x1> <153115422491.7447.12479559048433925372.stgit@alrua-x1> <1535528167.5215.15.camel@sipsolutions.net> <87a7p54jed.fsf@toke.dk> <1535534678.5215.23.camel@sipsolutions.net> Date: Wed, 29 Aug 2018 12:09:41 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <871sah4h7e.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [RFC v2 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: Wed, 29 Aug 2018 10:09:44 -0000 Johannes Berg writes: > On Wed, 2018-08-29 at 11:22 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > >> > We're also working on adding a TXQ for (bufferable) management packets >> > - I wonder how that should interact here? Always be scheduled first? >>=20 >> Ah, cool! It may be that it should be given priority, yeah. Presently, >> the multicast queue just rotates in the RR with the others, but is never >> throttled as it doesn't have an airtime measure (though perhaps it >> should)? But that might not be desirable for management frames, as >> presumable those need to go out as fast as possible? > > Good question. I guess the multicast should have an airtime measure, > but I don't think we want to do accounting on the management. That > really should be few frames, and we want them out ASAP in most cases. Yup, makes sense. >> Hmm, I seem to recall thinking about just putting the call to >> schedule_txq() into drv_wake_tx_queue; don't remember why I ended up >> dropping that; but will take another look at whether it makes sense to >> combine things. > > I was thinking the other way around - but that doesn't work since you'd > loop from the driver to itself. This way might work, I guess, hadn't > considered that. > > Might be better anyway though to make a new inline that does both, since > the drv_() calls usually really don't do much on their own (other than > checks, and in one case backward compatibility code, but still) ACK, I'll look into that. -Toke