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 1ZEgkA-0002o7-5A for ath10k@lists.infradead.org; Mon, 13 Jul 2015 16:38:15 +0000 Message-ID: <55A3E960.9060808@candelatech.com> Date: Mon, 13 Jul 2015 09:37:52 -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> <559FC4F4.5020008@candelatech.com> In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "ath10k" Errors-To: ath10k-bounces+kvalo=adurom.com@lists.infradead.org To: Michal Kazior Cc: "linux-wireless@vger.kernel.org" , ath10k T24gMDcvMTMvMjAxNSAwMTowNSBBTSwgTWljaGFsIEthemlvciB3cm90ZToKPiBPbiAxMCBKdWx5 IDIwMTUgYXQgMTU6MTMsIEJlbiBHcmVlYXIgPGdyZWVhcmJAY2FuZGVsYXRlY2guY29tPiB3cm90 ZToKPj4gT24gMDcvMDkvMjAxNSAxMDoyMCBQTSwgTWljaGFsIEthemlvciB3cm90ZToKPj4+Cj4+ PiBPbiAxMCBKdWx5IDIwMTUgYXQgMDI6MDMsIEJlbiBHcmVlYXIgPGdyZWVhcmJAY2FuZGVsYXRl Y2guY29tPiB3cm90ZToKPj4+Pgo+Pj4+IFN1cHBvc2Ugb25lIGlzIGRvaW5nIGhlYXZ5IGRvd25s b2FkIChBUCAtPiBwZWVyIHRyYWZmaWMpLCBhbmQgdGhlcmUgYXJlCj4+Pj4gbG90cyBvZiBmcmFt ZXMgaW4gdGhlCj4+Pj4gTklDJ3MgdHggYnVmZmVycyAoYXRoMTBrIGZpcm13YXJlLCBpbiB0aGlz IGNhc2UpLgo+Pj4+Cj4+Pj4gVGhlbiwgcGVlciBzZW5kcyBhIHBvd2VyLXNhdmUgcGt0IHRlbGxp bmcgQVAgaXQgaXMgZ29pbmcgb2ZmLWNoYW5uZWwgb3IKPj4+PiBvdGhlcndpc2UKPj4+PiB3aWxs IGJlIHVuYXZhaWxhYmxlLgo+Pj4KPj4+Cj4+PiBJIGFzc3VtZSB5b3UncmUgZXhwbG9yaW5nIHRo ZSB3b3JzdC1jYXNlIHNjZW5hcmlvIHdoZW4gYWxsIHR4IGJ1ZmZlcnMKPj4+IGFyZSBjb25zdW1l ZCBhbmQgcGVlciBnb2VzIHRvIHNsZWVwLCBhbSBJIGNvcnJlY3Q/Cj4+Cj4+Cj4+IEV2ZW4gaWYg bm90IGFic29sdXRlbHkgYWxsLi4uc2VlbXMgbGlrZSB3ZSBzaG91bGQgZmx1c2ggdGhlbSBxdWlj ayBhbmQKPj4gbGV0IHRoZSBPUyBkbyB0aGUgYnVmZmVyaW5nIGJ5IGhhdmluZyBpdCByZS1zZW5k IHdoZW4gUFMgaXMgZGlzYWJsZWQKPj4gYWdhaW4uICBBIGZldyBzdGF0aW9ucyBpbiBQUyBjb3Vs ZCBxdWlja2x5IGVhdCBhbGwgZmlybXdhcmUgdHggYnVmZmVycywgbm90Cj4+IGV2ZW4KPj4gaW5j bHVkaW5nIHRoZSB3bWktbWd0LWZyYW1lIGlzc3VlLiAgSSd2ZSBmaXhlZCB0aGUgdHgtc3RhdHVz IGluIG15IENUCj4+IGZpcm13YXJlIG5vdy4uLmNvdWxkIHBvc3NpYmx5Cj4+IGFkZCBhbm90aGVy IHR4LXN0YXR1cyAobGlrZSB0eC1kcm9wcGVkLVBTKSB0byBiZXR0ZXIgZGVhbCB3aXRoIHRoaXM/ ICBJCj4+IHRoaW5rCj4+IEkgbWF5IHRyeSB0byBtYWtlIG15IGZpcm13YXJlIGFibGUgdG8gdHJh bnNtaXQgbWd0IGZyYW1lcyBvdmVyIGh0dCBhcyB3ZWxsLAo+PiB3aGljaCBzaG91bGQgaGVscCB3 aXRoIHNvbWUgb2YgdGhpcyBhcyB3ZWxsLgo+IAo+IEhtbS4uIEkgZ3Vlc3MgeW91J2QgbmVlZCB0 byBlaXRoZXIgcmUtaW1wbGVtZW50IHBlci1zdGEgYnVmZmVyaW5nIGluCj4gYXRoMTBrIG9yIG1h a2UgYXRoMTBrIHVzZSBtYWM4MDIxMSdzIGltcGxlbWVudGF0aW9uIGZvciBBUCBQUy4gRWl0aGVy Cj4gd2F5IEkgdGhpbmsgaXQgbWlnaHQgYmUgcHJldHR5IHRyaWNreS4gVGhlIGxhdHRlciB3aWxs IG5lZWQgTnVsbEZ1bmMKPiBmcmFtZXMgYW5kIFBTLVBvbGxzIHRvIGJlIHJlcG9ydGVkIHRvIG1h YzgwMjExLiBJJ20gbm90IHN1cmUgaWYgdGhlc2UKPiBnZXQgZGVsaXZlcmVkIHdpdGhvdXQgbW9u aXRvciB2ZGV2LiBFdmVuIGlmIHRoZXkgYXJlIGl0IHdvdWxkIHdvcmsKPiB3aXRoIFFDQTk4OFgg YW5kIDEwLngvNjM2IG9ubHkuIFFDQTYxN1g0IGh3My54KyBoYXMgRnVsbCBSeCBvZmZsb2FkCj4g YW5kIGlzIGluY2FwYWJsZSBvZiBhY3RpbmcgYXMgYSBtb25pdG9yIGVmZmVjdGl2ZWx5IChpdCBk b2Vzbid0IHJlcG9ydAo+IHRvbnMgb2YgZnJhbWUgdHlwZXMpLiBBbmQgdGhlcmUncyBRQ0E5OVgw IG9uIHRoZSBob3Jpem9uIHdoaWNoIEkgZG9uJ3QKPiBrbm93IG11Y2ggYWJvdXQgeWV0LgoKSSBz dXNwZWN0IHRoaXMgc29ydCBvZiB0aGluZyB3aWxsIHJlcXVpcmUgYXQgbGVhc3Qgc29tZSBmaXJt d2FyZSBjaGFuZ2VzLApzbyBJIGFtIG5vdCBwbGFubmluZyB0byBnbyBvdXQgb2YgbXkgd2F5IHRv IGhhY2sgYXJvdW5kIHVwc3RyZWFtIGZpcm13YXJlCmxpbWl0YXRpb25zIGlmIEkgY2FuIGZpeCBD VCBmaXJtd2FyZSBkbyB0byBpdCBiZXR0ZXIuCgpJIHRoaW5rIGl0IHdvdWxkIGJlIGVhc3kgZW5v dWdoIHRvIG1vZGlmeSBmaXJtd2FyZSB0byBtYWtlIGl0IHBhc3MKc29tZSBleHRyYSBmcmFtZXMg dXAgdGhlIHN0YWNrLgoKQXQgbGVhc3QgYXMgcm91Z2ggb3V0bGluZSwgZG9lcyB0aGlzIHNlZW0g bGlrZSBpdCBjb3VsZCB3b3JrOgoKMSkgIFBhc3MgTnVsbEZ1bmMgJiBQUyBQb2xsIGZyYW1lcyB1 cCB0byBob3N0CgoyKSAgUmlwIG91dCBhbGwgb2YgdGhlIHBvd2VyLXNhdmUgc3VwcG9ydCBpbiB0 aGUgZmlybXdhcmUuCgozKSAgSW1wbGVtZW50IGEgJ2ZsdXNoLXBlZXItcHMnIEFQSSB0aGF0IGxl dHMgaG9zdCB0ZWxsIGZpcm13YXJlCnRvIGRpc2NhcmQgYW55IHBlbmRpbmcgZnJhbWVzIGZvciBh IHBhcnRpY3VsYXIgcGVlciwgYW5kIGhhdmUgZmlybXdhcmUKdXNlIGEgbmV3IHR4IHN0YXR1cyAn VFhfRElTQ0FSRF9QUycuICBJIGRvbid0IHRoaW5rIHdlIGNhbiByZXVzZQp0aGUgcGxhaW4gJ0RJ U0NBUkQnIHR4LXN0YXR1cyBzaW5jZSBpdCAqaXMqIHVzZWQgZm9yIGF0IGxlYXN0IGEgZmV3CnRo aW5ncywgYW5kIHNvIGhvc3Qgd291bGQgaGF2ZSBhIGhhcmQgdGltZSBrbm93aW5nIGhvdyB0byBo YW5kbGUKdGhhdCByeCBjb2RlIHByb3Blcmx5LgoKNCkgIFNvbWVob3cgbGV0IG1hYzgwMjExIHN0 YWNrIGtub3cgdGhhdCB0aGUgVFhfRElTQ0FSRF9QUyBmcmFtZXMgYXJlCnRvIGJlIHJldHJpZWQg dy9vdXQgZGVjcmVtZW50aW5nIHRoZSByZXRyeSBjb3VudGVyIG9uY2UgUFMgbG9naWMgZGljdGF0 ZXMKZnJhbWVzIGNhbiBiZSBzZW50IGFnYWluLgoKPiAKPiBJJ20gbm90IHN1cmUgYnV0IGZsdXNo ZWQgZnJhbWVzIGNvdWxkIGJlIHJlcG9ydGVkIGFzICJkaXNjYXJkIi4gSWYKPiB0aGF0IHdlcmUg dGhlIGNhc2Ugd2UgY291bGQgcHJvYmFibHkgdXNlIHRoYXQgaW5zdGVhZCBvZiBhIGN1c3RvbQo+ IHR4LWRyb3BwZWQtcHMuICJkaXNjYXJkIiBpcyByYXRoZXIgcmFyZSBhbmQgaGFwcGVucyBpbiBz b21lIGNvcm5lcgo+IGNhc2VzIGZyb20gd2hhdCBJJ3ZlIHNlZW4gc28gZmFyIChtaXNzaW5nIHBl ZXIgZW50cmllcywgYm9ndXMgZnJhbWVzLAo+IGV0Yykgb25seS4KPiAKPiBJdCdkIGJlIGdyZWF0 IGlmIGFsbCBhdGgxMGsgaHcvZncgcmV2aXNpb25zIGNhbiBiZW5lZml0LgoKTWF5YmUgaWYgSSBj YW4gaW1wbGVtZW50IGl0IGluIENUIGZpcm13YXJlLCBzb21lb25lIHVwc3RyZWFtCndpbGwgYmUg d2lsbGluZyB0byBhY2NlcHQgc2ltaWxhciBmaXJtd2FyZSBjaGFuZ2VzIGludG8gdGhlCm9mZmlj aWFsIGZpcm13YXJlLiAgT3IgaWYgbm90LCB0aGUgYWx0ZXJuYXRpdmUgZmlybXdhcmUgd2lsbAph dCBsZWFzdCBnaXZlIHVzZXJzIG1vcmUgb3B0aW9ucy4KCj4+IEluIGN1cnJlbnQgdGVzdGluZywg aXQgYWN0dWFsbHkgc2VlbXMgbGlrZSBhdGgxMGsgZmlybXdhcmUgKG9yIG1heWJlIGhpZ2hlcgo+ PiB1cCkgaXMgY29tcGxldGVseQo+PiBpZ25vcmluZyB0aGUgUFMgYml0Li5idXQgSSBoYXZlIGEg bG90IG1vcmUgZGVidWdnaW5nIHRvIGRvIGJlZm9yZSBJJ20KPj4gY2VydGFpbiBvZiB0aGlzLiAg UG9zc2libHkgcGVlciBpcyBiZWluZyBkb2RneS4KPiAKPiBDYW4geW91IGVsYWJvcmF0ZSBtb3Jl LCBwbGVhc2U/IFdoYXQgZG8geW91IG1lYW4gJ2lnbm9yZXMgUFMgYml0Jz8KPiBXb3VsZG4ndCB0 aGF0IG1ha2UgYSB0b3RhbCBtZXNzIHdpdGggdHJhZmZpYz8KCkZ1cnRoZXIgZGVidWdnaW5nIHNo b3dlZCB0aGF0IHRoZSBwZWVyIHdlbnQgaW50byBQUyBhbmQgc3RheWVkIHRoYXQKd2F5IGZvciBh Ym91dCA0IHNlY29uZHMuICBUaGVuLCBhdGgxMGsgcmVwb3J0ZWQgbG90cyBvZiB0eC1mYWlsdXJl cwooYW5kIGEgc25pZmYgc2hvd2VkIGxvdHMgb2YgcmV0cmllZCBmcmFtZXMgb24gdGhlIGFpciBh dCB0aGF0IHRpbWUpLiAgSSBkaWQgbm90IHNlZQp0aGF0IHNwZWNpYWwgJ3BlZXItcHMtb3V0LW9m LXN5bmMnIG1lc3NhZ2UgZnJvbSB0aGUgZmlybXdhcmUsIHNvIHNvbWV0aGluZwplbHNlIHdhcyBj YXVzaW5nIHRob3NlIGZyYW1lcyB0byBzdGFydCBhZ2FpbiwgaXQgc2VlbXMuCgpJIGRlY2lkZWQg dG8gc3BlbmQgc29tZSBlZmZvcnQgb24gbWd0LW92ZXItaHR0IGZpcnN0LCB0aGVuIHdpbGwgbG9v ayBpbnRvCnRoaXMgaXNzdWUgbW9yZSBjbG9zZWx5LgoKPj4+PiBXaGF0IGlzIHRoZSBhcHByb3By aWF0ZSBiZWhhdmlvdXIgZnJvbSB0aGUgQVA/ICBDYW4gdGhlIGZpcm13YXJlIGp1c3QKPj4+PiBk cm9wIGFsbCB0aG9zZSB0eCBmcmFtZXMgdG8KPj4+PiBtYWtlIHJvb20gdG8gaGFuZGxlIG90aGVy IHN0YXRpb25zPyAgTWF5YmUgcmVwb3J0IEFDSyBmYWlsdXJlIGFuZCBob3BlCj4+Pj4gdGhlIHVw cGVyIGxldmVsIHN0YWNrcwo+Pj4+IHJldHJhbnNtaXQgYXMgYXBwcm9wcmlhdGU/Cj4+Pj4KPj4+ PiBPciwgaXMgdGhlIGhvc3Qgc3VwcG9zZWQgdG8gZmx1c2ggdGhlIHBlZXIncyBwYWNrZXRzIHRv IGNsZWFyIG91dCB0aGUKPj4+PiBmcmFtZXM/Cj4+Pj4KPj4+PiBPciwgaXMgZmlybXdhcmUgc29t ZWhvdyBzdXBwb3NlZCB0byBrZWVwIGFsbCB0aGUgZnJhbWVzIGZvciB3aGVuIHRoZSBwZWVyCj4+ Pj4gY29tZXMgYmFjaz8KPj4+Cj4+Pgo+Pj4gRmlybXdhcmUgd2lsbCBrZWVwIGZyYW1lcyBidWZm ZXJlZCB1bnRpbCBzdGF0aW9uIHdha2VzIHVwIGFnYWluLgo+Pj4KPj4+IFRoZXJlJ3MgYSB0aW1l b3V0IHRvIGRldGVjdCBzdGFsZSBzdGF0aW9ucyBhcyBmYXIgYXMgSSdtIGF3YXJlIGFuZCB0aGUK Pj4+IGRlZmF1bHQgdmFsdWUgaXMgMTBzIChzb3VuZHMgZmFtaWxpYXI/IHRoaXMgZ29lcyBiYWNr IHRvIG1nbXQgdHgvCj4+PiBjcmVkaXQgc3RhcnZhdGlvbikuIFRoaXMgbWFrZXMgdG8gaGFuZGxl IHN0YXRpb25zIHRoYXQgZ28gdG8gc2xlZXAgYW5kCj4+PiB0aGVuIG91dCBvZiByYW5nZS9hd2F5 LiBBUCBkb2Vzbid0IG5lZWQgdG8ga2VlcCBmcmFtZXMgYnVmZmVyZWQgdGlsbAo+Pj4gdGhlIGVu ZCBvZiB0aW1lLiBPbmNlIHRoZSB0aW1lb3V0IGlzIGhpdCBmaXJtd2FyZSBzdG9wcyBjYXJpbmcg YWJvdXQKPj4+IHN0YXRpb24ncyBsYXN0IHNlZW4gc2xlZXAgc3RhdGUgdHJhbnNpdGlvbiBhbmQg bWFya3MgaXQgYXMgYXdha2UgYW5kCj4+PiBqdXN0IHNlbmRzIGZyYW1lcyB0byBpdCAod2l0aCB0 b25zIG9mIHJldHJhbnNtaXRzIGlmIGl0J3MgcmVhbGx5IG5vdAo+Pj4gdGhlcmUgYW55bW9yZSBz aW5jZSB0aGVyZSdkIGJlIG5vb25lIHRvIEFDSykgLSBpbiB3aGljaCBjYXNlIHlvdSdsbAo+Pj4g Z2V0IG5vX2Fjaz0xIGluIHR4IHN0YXR1cy4KPj4KPj4KPj4gV2UgZG8gc2VlIGxvdHMgb2Ygbm8t YWNrLCBoYWQgdG8gdGVsbCBob3N0YXBkIHRvIGlnbm9yZSBub2FjayBmYWlsdXJlcwo+PiBvciBj b25uZWN0aW9uIHRvIHBlZXIgd2FzIGxvc3QuICBCdXQsIHBlZXIgc2hvdWxkIG5vdCBoYXZlIGJl ZW4gZ29uZSBmb3IKPj4gMTArIHNlY29uZHMgaW4gdGhpcyBjYXNlLgo+IAo+IEkgdGhpbmsgSSd2 ZSBzZWVuIHNvbWUgZGlmZmVyZW5jZXMgYmV0d2VlbiBmZXcgZmlybXdhcmUgcmV2aXNpb25zIG92 ZXIKPiB0aW1lIChJIGRpZG4ndCB0cmFjayBpdCB0aG91Z2gpLiBZb3UgbWlnaHQgd2FudCB0byBp bnNwZWN0IFR4Cj4gZGVzY3JpcHRvcnMgY2FyZWZ1bGx5IGluIGZ3IGFuZCBjb21wYXJlIHRoZW0g dG8gd2hhdCBpcyByZXBvcnRlZCB2aWEKPiBIVFQgVHguCgpJIHNwZW50IHNvbWUgZWZmb3J0IGF1 ZGl0aW5nIHRoZSB0eC1zdGF0dXMgaW4gQ1QgZmlybXdhcmUsIHNvIEkgdGhpbmsKaXQgaXMgcHJv cGVyIG5vdy4gIEkgY291bGQgYmUgd3JvbmcsIGhvd2V2ZXIuLi4KCj4+Cj4+IFRoYXQgc2VlbXMg bGlrZSBhIGhvcnJpYmxlIHdhc3RlIG9mIHRpbWUgcmV0cmFuc21pdHRpbmcgcGFja2V0cywgYnkg dGhlIHdheS4KPiAKPiBJJ20gZ3Vlc3NpbmcgdGhlIGFib3ZlIGNvdmVycyBzb21lIHNvcnQgb2Yg YSByYXJlIGNvcm5lciBjYXNlLi4KClllcywgSSB0aGluayBzby4gIEknbGwgaHVudCBpdCBkb3du IGV2ZW50dWFsbHkgaWYgYWxsIGdvZXMgYWNjb3JkaW5nCnRvIHBsYW4uCgo+Pj4gU2VlOiBXTUlf MTBYX1ZERVZfUEFSQU1fQVBfREVURUNUX09VVF9PRl9TWU5DX1NMRUVQSU5HX1NUQV9USU1FX1NF Q1MKPj4+Cj4+PiBJZGVhbGx5IHRoZXJlIHNob3VsZCBiZSBsaXR0bGUgdG8gbm8gYnVmZmVyIGJs b2F0IGJ1dCBpdCdzIGRpZmZpY3VsdAo+Pj4gdG8gZG8gdGhhdCBjb25zaWRlcmluZyBhZ2dyZWdh dGlvbiBzaXplcyBvZiAxMWFjLi4KPj4KPj4KPj4gQXRoMTBrIHdpbGwgbm90IGFnZ3JlZ2F0ZSBt b3JlIHRoYW4gYWJvdXQgMzAgZnJhbWVzIGFzIGZhciBhcyBJIGNhbiB0ZWxsLAo+PiAobWF5YmUg MyB0aW1lcyB0aGF0IGlmIGFtc2R1IGlzIGhhcHBlbmluZyBhcyB3ZWxsPykuICBTdGFuZGFyZCBk cml2ZXIgaXMKPj4gdXNpbmcKPj4gbW9yZSB0aGFuIDEwMDAgYnVmZmVycywgYW5kIHN0b2NrIGZp cm13YXJlIHdvbid0IGV2ZW4gbGV0IHlvdSBjb25maWd1cmUgdGhpcwo+PiB0byBiZSBzbWFsbGVy IHRoYW4gYWJvdXQgMTAyNCAodGhvdWdoIG1heWJlIGRyaXZlciBjb3VsZCBzdGlsbCB1c2UgbGVz cwo+PiBhbmQgZmlybXdhcmUgd291bGRuJ3QgY2FyZSwgbm90IHN1cmUpLgo+IAo+IEkgdGhpbmsg aXQnZCBiZSBtb3JlIGFjY3VyYXRlIHRvIHNheSAxMC4xIChzaW5jZSB0aGF0J3Mgd2hhdCB5b3Ug dXNlCj4gbWFpbmx5LCByaWdodD8pIGRvZXNuJ3QgYWdncmVnYXRlIG1vcmUgdGhhbiAzMCBmcmFt ZXMuIFRoZXJlJ3MgMTAuMiwKPiAxMC4yLjQsIDYzNiwgYW5kIHRoZW4gdGhlcmUncyBxY2E2MXg0 IHdpdGggYW5vdGhlciBmaXJtd2FyZSBicmFuY2guCj4gYXRoMTBrIGRvZXNuJ3QgcmVhbGx5IGhh dmUgbXVjaCB0byB0ZWxsIGluIGFnZ3JlZ2F0aW9uLgo+IAo+IDExYWMgYWdncmVnYXRpb24gY2Fu IGJlIGFzIGJpZyBhcyAxTUJ5dGUgYXMgZmFyIGFzIEkgY2FuIHJlbWVtYmVyLgo+IFRoaXMgbWVh bnMgaXQncyBpbmhlcmVudGx5IHRyaWNreSB0byBhdm9pZCBidWZmZXIgYmxvYXQgYW5kIGtlZXAg bWF4Cj4gdGhyb3VnaHB1dCB3aXRoIHdpZmkgLSB0aGF0J3Mgd2hhdCBJIG9yaWdpbmFsbHkgbWVh bnQuCgpFdmVuIGlmIGl0ICpjYW4qIGJlIGxhcmdlciwgbWF5YmUgdGhlcmUgaXMgbm8gcmVhc29u IHRvIGFjdHVhbGx5IGRvIHRoaXMKaW4gcHJhY3RpY2U/ICBGb3IgaW5zdGFuY2UsIGlmIHBlZXJz IGdvaW5nIHRvIHNsZWVwIGFuZCBnb2luZyBvdXQgb2YgcmFuZ2UKKG9yIGNyYXBwaW5nIHVwIHRo ZWlyIG93biBQUyBzdGF0ZSBkdWUgdG8gYnVncyBvciBtYWxpY2lvdXMgaW50ZW50KSBjYW4gZWZm ZWN0aXZlbHkgbGl2ZS1sb2NrCmFuIEFQIGZvciBldmVyeW9uZSBlbHNlLCB0aGF0IHNlZW1zIGxp a2UgYSBtdWNoIG1vcmUgc2VyaW91cyBidWcKdGhhbiBzbGlnaHRseSBzbG93ZXIgcGVyZm9ybWFu Y2Ugd2l0aCB0aGUgbGltaXRlZCBjYXNlcyB3aGVyZSB5b3UgY2FuIGFjdHVhbGx5CnVzZSB2ZXJ5 IGxhcmdlIGFnZ3JlZ2F0aW9ucy4KCkZvciBhIGNvbW1vbiBjYXNlIHdoZXJlIHlvdSBoYXZlIG1h bnkgc3RhdGlvbnMgY29ubmVjdGVkIHRvIGFuIEFQLCBkb2luZyB3b3JrCnRvIGdpdmUgZWFjaCBz dGF0aW9uIGEgbW9kZXN0IHNpemVkIGFnZ3JlZ2F0aW9uIG9wcG9ydHVuaXR5IGlzIGdvaW5nIHRv IGRvIHdheQptb3JlIGdvb2QgdGhhbiBtYWtpbmcgb25lIHN0YXRpb24gdmVyeSBmYXN0LCBJIHRo aW5rLgoKVGhhbmtzIGZvciBhbGwgdGhlIGNvbW1lbnRzIGFuZCB0aG91Z2h0cyEKCkJlbgoKCj4+ IEJ1dCBmaXhpbmcgYnVmZmVyIGJsb2F0IGluIGF0aDEwayBpcyBub3QgbXkgcHJpbWFyeSBjb25j ZXJuIGF0IHRoZSBtb21lbnQuCj4gCj4gU3VyZS4gTm9uZXRoZWxlc3MgeW91ciBwcm9ibGVtICpp cyogcmVsYXRlZCB0byBidWZmZXIgYmxvYXQuCj4gCj4gCj4gTWljaGHFggo+IAoKCi0tIApCZW4g R3JlZWFyIDxncmVlYXJiQGNhbmRlbGF0ZWNoLmNvbT4KQ2FuZGVsYSBUZWNobm9sb2dpZXMgSW5j ICBodHRwOi8vd3d3LmNhbmRlbGF0ZWNoLmNvbQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCmF0aDEwayBtYWlsaW5nIGxpc3QKYXRoMTBrQGxpc3RzLmlu ZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9h dGgxMGsK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail2.candelatech.com ([208.74.158.173]:46821 "EHLO mail2.candelatech.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751327AbbGMQhx (ORCPT ); Mon, 13 Jul 2015 12:37:53 -0400 Message-ID: <55A3E960.9060808@candelatech.com> (sfid-20150713_183756_739020_83A43B20) Date: Mon, 13 Jul 2015 09:37:52 -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> <559FC4F4.5020008@candelatech.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 07/13/2015 01:05 AM, Michal Kazior wrote: > On 10 July 2015 at 15:13, Ben Greear wrote: >> 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. > > Hmm.. I guess you'd need to either re-implement per-sta buffering in > ath10k or make ath10k use mac80211's implementation for AP PS. Either > way I think it might be pretty tricky. The latter will need NullFunc > frames and PS-Polls to be reported to mac80211. I'm not sure if these > get delivered without monitor vdev. Even if they are it would work > with QCA988X and 10.x/636 only. QCA617X4 hw3.x+ has Full Rx offload > and is incapable of acting as a monitor effectively (it doesn't report > tons of frame types). And there's QCA99X0 on the horizon which I don't > know much about yet. I suspect this sort of thing will require at least some firmware changes, so I am not planning to go out of my way to hack around upstream firmware limitations if I can fix CT firmware do to it better. I think it would be easy enough to modify firmware to make it pass some extra frames up the stack. At least as rough outline, does this seem like it could work: 1) Pass NullFunc & PS Poll frames up to host 2) Rip out all of the power-save support in the firmware. 3) Implement a 'flush-peer-ps' API that lets host tell firmware to discard any pending frames for a particular peer, and have firmware use a new tx status 'TX_DISCARD_PS'. I don't think we can reuse the plain 'DISCARD' tx-status since it *is* used for at least a few things, and so host would have a hard time knowing how to handle that rx code properly. 4) Somehow let mac80211 stack know that the TX_DISCARD_PS frames are to be retried w/out decrementing the retry counter once PS logic dictates frames can be sent again. > > I'm not sure but flushed frames could be reported as "discard". If > that were the case we could probably use that instead of a custom > tx-dropped-ps. "discard" is rather rare and happens in some corner > cases from what I've seen so far (missing peer entries, bogus frames, > etc) only. > > It'd be great if all ath10k hw/fw revisions can benefit. Maybe if I can implement it in CT firmware, someone upstream will be willing to accept similar firmware changes into the official firmware. Or if not, the alternative firmware will at least give users more options. >> 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. > > Can you elaborate more, please? What do you mean 'ignores PS bit'? > Wouldn't that make a total mess with traffic? Further debugging showed that the peer went into PS and stayed that way for about 4 seconds. Then, ath10k reported lots of tx-failures (and a sniff showed lots of retried frames on the air at that time). I did not see that special 'peer-ps-out-of-sync' message from the firmware, so something else was causing those frames to start again, it seems. I decided to spend some effort on mgt-over-htt first, then will look into this issue more closely. >>>> 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. > > I think I've seen some differences between few firmware revisions over > time (I didn't track it though). You might want to inspect Tx > descriptors carefully in fw and compare them to what is reported via > HTT Tx. I spent some effort auditing the tx-status in CT firmware, so I think it is proper now. I could be wrong, however... >> >> That seems like a horrible waste of time retransmitting packets, by the way. > > I'm guessing the above covers some sort of a rare corner case.. Yes, I think so. I'll hunt it down eventually if all goes according to plan. >>> 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). > > I think it'd be more accurate to say 10.1 (since that's what you use > mainly, right?) doesn't aggregate more than 30 frames. There's 10.2, > 10.2.4, 636, and then there's qca61x4 with another firmware branch. > ath10k doesn't really have much to tell in aggregation. > > 11ac aggregation can be as big as 1MByte as far as I can remember. > This means it's inherently tricky to avoid buffer bloat and keep max > throughput with wifi - that's what I originally meant. Even if it *can* be larger, maybe there is no reason to actually do this in practice? For instance, if peers going to sleep and going out of range (or crapping up their own PS state due to bugs or malicious intent) can effectively live-lock an AP for everyone else, that seems like a much more serious bug than slightly slower performance with the limited cases where you can actually use very large aggregations. For a common case where you have many stations connected to an AP, doing work to give each station a modest sized aggregation opportunity is going to do way more good than making one station very fast, I think. Thanks for all the comments and thoughts! Ben >> But fixing buffer bloat in ath10k is not my primary concern at the moment. > > Sure. Nonetheless your problem *is* related to buffer bloat. > > > Michał > -- Ben Greear Candela Technologies Inc http://www.candelatech.com