From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail2.candelatech.com ([208.74.158.173]) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZDY7h-0000ni-RJ for ath10k@lists.infradead.org; Fri, 10 Jul 2015 13:13:50 +0000 Message-ID: <559FC4F4.5020008@candelatech.com> Date: Fri, 10 Jul 2015 06:13:24 -0700 From: Ben Greear MIME-Version: 1.0 Subject: Re: How is AP supposed to handle power-save packets from peer? References: <559F0BEF.4000808@candelatech.com> In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: "ath10k" Errors-To: ath10k-bounces+kvalo=adurom.com@lists.infradead.org To: Michal Kazior Cc: "linux-wireless@vger.kernel.org" , ath10k T24gMDcvMDkvMjAxNSAxMDoyMCBQTSwgTWljaGFsIEthemlvciB3cm90ZToKPiBPbiAxMCBKdWx5 IDIwMTUgYXQgMDI6MDMsIEJlbiBHcmVlYXIgPGdyZWVhcmJAY2FuZGVsYXRlY2guY29tPiB3cm90 ZToKPj4gU3VwcG9zZSBvbmUgaXMgZG9pbmcgaGVhdnkgZG93bmxvYWQgKEFQIC0+IHBlZXIgdHJh ZmZpYyksIGFuZCB0aGVyZSBhcmUgbG90cyBvZiBmcmFtZXMgaW4gdGhlCj4+IE5JQydzIHR4IGJ1 ZmZlcnMgKGF0aDEwayBmaXJtd2FyZSwgaW4gdGhpcyBjYXNlKS4KPj4KPj4gVGhlbiwgcGVlciBz ZW5kcyBhIHBvd2VyLXNhdmUgcGt0IHRlbGxpbmcgQVAgaXQgaXMgZ29pbmcgb2ZmLWNoYW5uZWwg b3Igb3RoZXJ3aXNlCj4+IHdpbGwgYmUgdW5hdmFpbGFibGUuCj4KPiBJIGFzc3VtZSB5b3UncmUg ZXhwbG9yaW5nIHRoZSB3b3JzdC1jYXNlIHNjZW5hcmlvIHdoZW4gYWxsIHR4IGJ1ZmZlcnMKPiBh cmUgY29uc3VtZWQgYW5kIHBlZXIgZ29lcyB0byBzbGVlcCwgYW0gSSBjb3JyZWN0PwoKRXZlbiBp ZiBub3QgYWJzb2x1dGVseSBhbGwuLi5zZWVtcyBsaWtlIHdlIHNob3VsZCBmbHVzaCB0aGVtIHF1 aWNrIGFuZApsZXQgdGhlIE9TIGRvIHRoZSBidWZmZXJpbmcgYnkgaGF2aW5nIGl0IHJlLXNlbmQg d2hlbiBQUyBpcyBkaXNhYmxlZAphZ2Fpbi4gIEEgZmV3IHN0YXRpb25zIGluIFBTIGNvdWxkIHF1 aWNrbHkgZWF0IGFsbCBmaXJtd2FyZSB0eCBidWZmZXJzLCBub3QgZXZlbgppbmNsdWRpbmcgdGhl IHdtaS1tZ3QtZnJhbWUgaXNzdWUuICBJJ3ZlIGZpeGVkIHRoZSB0eC1zdGF0dXMgaW4gbXkgQ1Qg ZmlybXdhcmUgbm93Li4uY291bGQgcG9zc2libHkKYWRkIGFub3RoZXIgdHgtc3RhdHVzIChsaWtl IHR4LWRyb3BwZWQtUFMpIHRvIGJldHRlciBkZWFsIHdpdGggdGhpcz8gIEkgdGhpbmsKSSBtYXkg dHJ5IHRvIG1ha2UgbXkgZmlybXdhcmUgYWJsZSB0byB0cmFuc21pdCBtZ3QgZnJhbWVzIG92ZXIg aHR0IGFzIHdlbGwsCndoaWNoIHNob3VsZCBoZWxwIHdpdGggc29tZSBvZiB0aGlzIGFzIHdlbGwu CgpJbiBjdXJyZW50IHRlc3RpbmcsIGl0IGFjdHVhbGx5IHNlZW1zIGxpa2UgYXRoMTBrIGZpcm13 YXJlIChvciBtYXliZSBoaWdoZXIgdXApIGlzIGNvbXBsZXRlbHkKaWdub3JpbmcgdGhlIFBTIGJp dC4uYnV0IEkgaGF2ZSBhIGxvdCBtb3JlIGRlYnVnZ2luZyB0byBkbyBiZWZvcmUgSSdtCmNlcnRh aW4gb2YgdGhpcy4gIFBvc3NpYmx5IHBlZXIgaXMgYmVpbmcgZG9kZ3kuCgoKPj4gV2hhdCBpcyB0 aGUgYXBwcm9wcmlhdGUgYmVoYXZpb3VyIGZyb20gdGhlIEFQPyAgQ2FuIHRoZSBmaXJtd2FyZSBq dXN0IGRyb3AgYWxsIHRob3NlIHR4IGZyYW1lcyB0bwo+PiBtYWtlIHJvb20gdG8gaGFuZGxlIG90 aGVyIHN0YXRpb25zPyAgTWF5YmUgcmVwb3J0IEFDSyBmYWlsdXJlIGFuZCBob3BlIHRoZSB1cHBl ciBsZXZlbCBzdGFja3MKPj4gcmV0cmFuc21pdCBhcyBhcHByb3ByaWF0ZT8KPj4KPj4gT3IsIGlz IHRoZSBob3N0IHN1cHBvc2VkIHRvIGZsdXNoIHRoZSBwZWVyJ3MgcGFja2V0cyB0byBjbGVhciBv dXQgdGhlIGZyYW1lcz8KPj4KPj4gT3IsIGlzIGZpcm13YXJlIHNvbWVob3cgc3VwcG9zZWQgdG8g a2VlcCBhbGwgdGhlIGZyYW1lcyBmb3Igd2hlbiB0aGUgcGVlciBjb21lcyBiYWNrPwo+Cj4gRmly bXdhcmUgd2lsbCBrZWVwIGZyYW1lcyBidWZmZXJlZCB1bnRpbCBzdGF0aW9uIHdha2VzIHVwIGFn YWluLgo+Cj4gVGhlcmUncyBhIHRpbWVvdXQgdG8gZGV0ZWN0IHN0YWxlIHN0YXRpb25zIGFzIGZh ciBhcyBJJ20gYXdhcmUgYW5kIHRoZQo+IGRlZmF1bHQgdmFsdWUgaXMgMTBzIChzb3VuZHMgZmFt aWxpYXI/IHRoaXMgZ29lcyBiYWNrIHRvIG1nbXQgdHgvCj4gY3JlZGl0IHN0YXJ2YXRpb24pLiBU aGlzIG1ha2VzIHRvIGhhbmRsZSBzdGF0aW9ucyB0aGF0IGdvIHRvIHNsZWVwIGFuZAo+IHRoZW4g b3V0IG9mIHJhbmdlL2F3YXkuIEFQIGRvZXNuJ3QgbmVlZCB0byBrZWVwIGZyYW1lcyBidWZmZXJl ZCB0aWxsCj4gdGhlIGVuZCBvZiB0aW1lLiBPbmNlIHRoZSB0aW1lb3V0IGlzIGhpdCBmaXJtd2Fy ZSBzdG9wcyBjYXJpbmcgYWJvdXQKPiBzdGF0aW9uJ3MgbGFzdCBzZWVuIHNsZWVwIHN0YXRlIHRy YW5zaXRpb24gYW5kIG1hcmtzIGl0IGFzIGF3YWtlIGFuZAo+IGp1c3Qgc2VuZHMgZnJhbWVzIHRv IGl0ICh3aXRoIHRvbnMgb2YgcmV0cmFuc21pdHMgaWYgaXQncyByZWFsbHkgbm90Cj4gdGhlcmUg YW55bW9yZSBzaW5jZSB0aGVyZSdkIGJlIG5vb25lIHRvIEFDSykgLSBpbiB3aGljaCBjYXNlIHlv dSdsbAo+IGdldCBub19hY2s9MSBpbiB0eCBzdGF0dXMuCgpXZSBkbyBzZWUgbG90cyBvZiBuby1h Y2ssIGhhZCB0byB0ZWxsIGhvc3RhcGQgdG8gaWdub3JlIG5vYWNrIGZhaWx1cmVzCm9yIGNvbm5l Y3Rpb24gdG8gcGVlciB3YXMgbG9zdC4gIEJ1dCwgcGVlciBzaG91bGQgbm90IGhhdmUgYmVlbiBn b25lIGZvcgoxMCsgc2Vjb25kcyBpbiB0aGlzIGNhc2UuCgpUaGF0IHNlZW1zIGxpa2UgYSBob3Jy aWJsZSB3YXN0ZSBvZiB0aW1lIHJldHJhbnNtaXR0aW5nIHBhY2tldHMsIGJ5IHRoZSB3YXkuCgo+ Cj4gU2VlOiBXTUlfMTBYX1ZERVZfUEFSQU1fQVBfREVURUNUX09VVF9PRl9TWU5DX1NMRUVQSU5H X1NUQV9USU1FX1NFQ1MKPgo+IElkZWFsbHkgdGhlcmUgc2hvdWxkIGJlIGxpdHRsZSB0byBubyBi dWZmZXIgYmxvYXQgYnV0IGl0J3MgZGlmZmljdWx0Cj4gdG8gZG8gdGhhdCBjb25zaWRlcmluZyBh Z2dyZWdhdGlvbiBzaXplcyBvZiAxMWFjLi4KCkF0aDEwayB3aWxsIG5vdCBhZ2dyZWdhdGUgbW9y ZSB0aGFuIGFib3V0IDMwIGZyYW1lcyBhcyBmYXIgYXMgSSBjYW4gdGVsbCwKKG1heWJlIDMgdGlt ZXMgdGhhdCBpZiBhbXNkdSBpcyBoYXBwZW5pbmcgYXMgd2VsbD8pLiAgU3RhbmRhcmQgZHJpdmVy IGlzIHVzaW5nCm1vcmUgdGhhbiAxMDAwIGJ1ZmZlcnMsIGFuZCBzdG9jayBmaXJtd2FyZSB3b24n dCBldmVuIGxldCB5b3UgY29uZmlndXJlIHRoaXMKdG8gYmUgc21hbGxlciB0aGFuIGFib3V0IDEw MjQgKHRob3VnaCBtYXliZSBkcml2ZXIgY291bGQgc3RpbGwgdXNlIGxlc3MKYW5kIGZpcm13YXJl IHdvdWxkbid0IGNhcmUsIG5vdCBzdXJlKS4KQnV0IGZpeGluZyBidWZmZXIgYmxvYXQgaW4gYXRo MTBrIGlzIG5vdCBteSBwcmltYXJ5IGNvbmNlcm4gYXQgdGhlIG1vbWVudC4KClRoYW5rcywKQmVu Cgo+Cj4KPiBNaWNoYcWCCj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwo+IGF0aDEwayBtYWlsaW5nIGxpc3QKPiBhdGgxMGtAbGlzdHMuaW5mcmFkZWFk Lm9yZwo+IGh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vYXRoMTBr Cj4KCgotLSAKQmVuIEdyZWVhciA8Z3JlZWFyYkBjYW5kZWxhdGVjaC5jb20+CkNhbmRlbGEgVGVj aG5vbG9naWVzIEluYyAgaHR0cDovL3d3dy5jYW5kZWxhdGVjaC5jb20KCgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwphdGgxMGsgbWFpbGluZyBsaXN0CmF0 aDEwa0BsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxt YW4vbGlzdGluZm8vYXRoMTBrCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail2.candelatech.com ([208.74.158.173]:43649 "EHLO mail2.candelatech.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754228AbbGJNNZ (ORCPT ); Fri, 10 Jul 2015 09:13:25 -0400 Message-ID: <559FC4F4.5020008@candelatech.com> (sfid-20150710_151329_159776_DBC25231) Date: Fri, 10 Jul 2015 06:13:24 -0700 From: Ben Greear MIME-Version: 1.0 To: Michal Kazior CC: "linux-wireless@vger.kernel.org" , ath10k Subject: Re: How is AP supposed to handle power-save packets from peer? References: <559F0BEF.4000808@candelatech.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Sender: linux-wireless-owner@vger.kernel.org List-ID: On 07/09/2015 10:20 PM, Michal Kazior wrote: > On 10 July 2015 at 02:03, Ben Greear wrote: >> Suppose one is doing heavy download (AP -> peer traffic), and there are lots of frames in the >> NIC's tx buffers (ath10k firmware, in this case). >> >> Then, peer sends a power-save pkt telling AP it is going off-channel or otherwise >> will be unavailable. > > I assume you're exploring the worst-case scenario when all tx buffers > are consumed and peer goes to sleep, am I correct? Even if not absolutely all...seems like we should flush them quick and let the OS do the buffering by having it re-send when PS is disabled again. A few stations in PS could quickly eat all firmware tx buffers, not even including the wmi-mgt-frame issue. I've fixed the tx-status in my CT firmware now...could possibly add another tx-status (like tx-dropped-PS) to better deal with this? I think I may try to make my firmware able to transmit mgt frames over htt as well, which should help with some of this as well. In current testing, it actually seems like ath10k firmware (or maybe higher up) is completely ignoring the PS bit..but I have a lot more debugging to do before I'm certain of this. Possibly peer is being dodgy. >> What is the appropriate behaviour from the AP? Can the firmware just drop all those tx frames to >> make room to handle other stations? Maybe report ACK failure and hope the upper level stacks >> retransmit as appropriate? >> >> Or, is the host supposed to flush the peer's packets to clear out the frames? >> >> Or, is firmware somehow supposed to keep all the frames for when the peer comes back? > > Firmware will keep frames buffered until station wakes up again. > > There's a timeout to detect stale stations as far as I'm aware and the > default value is 10s (sounds familiar? this goes back to mgmt tx/ > credit starvation). This makes to handle stations that go to sleep and > then out of range/away. AP doesn't need to keep frames buffered till > the end of time. Once the timeout is hit firmware stops caring about > station's last seen sleep state transition and marks it as awake and > just sends frames to it (with tons of retransmits if it's really not > there anymore since there'd be noone to ACK) - in which case you'll > get no_ack=1 in tx status. We do see lots of no-ack, had to tell hostapd to ignore noack failures or connection to peer was lost. But, peer should not have been gone for 10+ seconds in this case. That seems like a horrible waste of time retransmitting packets, by the way. > > See: WMI_10X_VDEV_PARAM_AP_DETECT_OUT_OF_SYNC_SLEEPING_STA_TIME_SECS > > Ideally there should be little to no buffer bloat but it's difficult > to do that considering aggregation sizes of 11ac.. Ath10k will not aggregate more than about 30 frames as far as I can tell, (maybe 3 times that if amsdu is happening as well?). Standard driver is using more than 1000 buffers, and stock firmware won't even let you configure this to be smaller than about 1024 (though maybe driver could still use less and firmware wouldn't care, not sure). But fixing buffer bloat in ath10k is not my primary concern at the moment. Thanks, Ben > > > Michał > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k > -- Ben Greear Candela Technologies Inc http://www.candelatech.com