From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:72ef::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 728D23B29E for ; Wed, 11 Oct 2017 10:34:53 -0400 (EDT) Received: by sipsolutions.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1e2I60-0005Ht-Fw; Wed, 11 Oct 2017 16:34:52 +0200 Message-ID: <1507732491.1998.39.camel@sipsolutions.net> From: Johannes Berg To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , make-wifi-fast@lists.bufferbloat.net, linux-wireless@vger.kernel.org Date: Wed, 11 Oct 2017 16:34:51 +0200 In-Reply-To: <87fuapbvws.fsf@toke.dk> 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> <87fuapbvws.fsf@toke.dk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.0-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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:34:53 -0000 On Wed, 2017-10-11 at 16:29 +0200, Toke Høiland-Jørgensen wrote: > Johannes Berg writes: > > > On Wed, 2017-10-11 at 16:06 +0200, Toke Høiland-Jørgensen 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. > > > > > > OK. But presumably it can't preempt packets already pushed to the > > > hardware, right? > > > > 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? Yes, but they need to be somehow taken off the queue to avoid reordering. Usually the firmware will filter them, but synchronisation is difficult, since what might happen is that some frames are already filtered, others aren't, and then the later ones actually need to go out while the earlier ones don't ... if that's not done, you get reordering and the state machines get out of sync. > 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? Hmm. I don't think the standard will actually help you much here, it just describes the over-the-air behaviour. Most of the complexity here comes from having to deal with driver buffering, mac80211 buffering, addressing the reordering problem (described above) from queuing frames for multiple stations on the same hw queue. johannes