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 12C963B2A4 for ; Tue, 10 Oct 2017 12:05:56 -0400 (EDT) Received: by sipsolutions.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1e1x2a-0003s2-35; Tue, 10 Oct 2017 18:05:56 +0200 Message-ID: <1507651555.26041.81.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: Tue, 10 Oct 2017 18:05:55 +0200 In-Reply-To: <20171010140208.1515-1-toke@toke.dk> (sfid-20171010_160341_258014_BDC1BDA8) References: <20171010140208.1515-1-toke@toke.dk> (sfid-20171010_160341_258014_BDC1BDA8) Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.0-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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: Tue, 10 Oct 2017 16:05:57 -0000 > In particular, I'm not sure what the right thing to do in regards to > PS wakeup is... Can you explain what you were _trying_ to do? I don't like calling this "driver_buffered" because that's already a term for frames that are buffered in the driver ... :-) PS is complicated, we basically transmit, in the following order: * filtered frames (tx_filtered) * buffered frames (ps_tx_buf) * regular frames This is when we _leave_ powersave. When we deliver frames while the station is sleeping (PS-Poll or U-APSD), they don't even go through the TXQ. They still come from this place, but currently go directly to the ->tx() method, which to me is actually pretty weird but that's what it is now. As I think I said in my other thread, we should probably eventually just get rid of ps_tx_buf entirely, instead just keeping the frames on the TXQ. Then, filtered can just be pushed onto txqi->frags [*], and we get rid of having that separately as well. Then, we've completely solved the wakeup scenario, we just start scheduling that TXQ normally again. For the deliver-while-sleeping (PS-Poll/U-APSD) scenario, I think the driver should still pull frames, after calling something like drv_release_buffered_frames(). We want this to be scheduled pretty much immediately, so we shouldn't just put the TXQ into the normal rotation, but otherwise it should work similarly - except limited to a certain number of frames [**]. In this case the driver probably needs to pull the frames using a different function so that we can a) tag the packets properly (more-data, EOSP) b) generate nulldata as EOSP container where needed Thus, it seems likely that we'll want a separate function, "pull for PS delivery" rather than the normal ieee80211_tx_dequeue(). johannes [*] ok not exactly, if there are frags there already things get messy. but we can probably solve that somehow without needing more special cases