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 5BBCC3B29E for ; Wed, 11 Oct 2017 10:29:10 -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=1507732149; bh=FOTys5Hokk62zuLNQy1FFHC+lqi1RY6eRJ3S8CpxT0E=; h=From:To:Subject:In-Reply-To:References:Date:From; b=MG4fSI3DhxBA/v969rKtA9bnWneTNQKmirm3Na5vLr7/OOx9gsZk/EMAVZNhfU8IO qJHRdJakowc8/QUAYHjMAG5AgI9wNKuXYTrQkRsaMbVrO9cvyxGBH19RceYLWC70qT Vt3Ypd0f3AjjOdwDoAcDe+wkfjrmbRfpes+ci01PzGJH56/33vu30/2lXIa7aFRe6e Hep6e1oDslowWP6qEWUFcETKR+bZ4PsiDGEfVF705s5RNFPtXZlZhajyjkhblUgoqL jFO7DIyoh69bDk/DtgggdLzswyTUEtqkVNPL0rH3jQRzmcdESPThaZmIwglhoC9PD+ vuKp3Re/9BqEQ== To: Johannes Berg , make-wifi-fast@lists.bufferbloat.net, linux-wireless@vger.kernel.org In-Reply-To: <1507731344.1998.36.camel@sipsolutions.net> References: <20171010140208.1515-1-toke@toke.dk> <1507651555.26041.81.camel@sipsolutions.net> <87fuaq7ubo.fsf@toke.dk> <1507711498.1998.18.camel@sipsolutions.net> <87tvz5pymm.fsf@toke.dk> <1507731344.1998.36.camel@sipsolutions.net> Date: Wed, 11 Oct 2017 16:29:07 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87fuapbvws.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 1/3] 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, 11 Oct 2017 14:29:10 -0000 Johannes Berg writes: > On Wed, 2017-10-11 at 16:06 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > >> > Hmm, not sure. We really want this to be scheduled pretty much >> > immediately because the other side will be waiting for the frames, >> > and >> > if we don't get an answer out quickly it'll have to assume we're >> > broken. I don't know what the limit here is for our firmware, but >> > we >> > should really get this out as soon as possible in this case. >>=20 >> OK. But presumably it can't preempt packets already pushed to the >> hardware, right?=20 > > True. If there are still packets scheduled then it needs even more > driver tricks to drop those back to tx_pending first ... Only for packets to the same station, right? >> So telling the driver to immediately schedule a packet, >> and making sure that the txq it gets from next_txq() is the right one >> should do the trick? But I guess it's a bit of a roundabout way, >> which may not be worth it to avoid an extra callback... > > Yeah, might work, but remember that we need to mangle the packet, and > for that we need to know how many packets will go out. E.g. with U- > APSD, if we tell the driver 8 packets are OK, and it only wants 6, then > that's acceptable, but we have to tag the last of those with EOSP ... > > So one way or another I think we need a separate callback here, and > perhaps just have the driver do the EOSP tagging, or have a separate > function to pull the frames so mac80211 can do the tagging, dunno. Yeah, sounds like it'll need a separate callback, or at least a flag. What part of the standard do I have to read to learn how this is supposed to work, BTW? Or even better, is there a resource that describes how PS works that is more accessible than the standard itself? > Note that this is only for _some_ drivers, others will implement much > of this in firmware. Right, of course. Fun times! :) -Toke