Return-path: Received: from nbd.name ([46.4.11.11]:59251 "EHLO nbd.name" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752983AbaCKPRB (ORCPT ); Tue, 11 Mar 2014 11:17:01 -0400 Message-ID: <531F28D8.8010001@openwrt.org> (sfid-20140311_161706_316037_993EE683) Date: Tue, 11 Mar 2014 16:16:40 +0100 From: Felix Fietkau MIME-Version: 1.0 To: Helmut Schaa CC: linux-wireless , John Linville Subject: Re: [PATCH 3.14] ath9k: fix ps-poll responses under a-mpdu sessions References: <1393073299-4831-1-git-send-email-nbd@openwrt.org> <531ED921.5040601@openwrt.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 2014-03-11 15:22, Helmut Schaa wrote: > On Tue, Mar 11, 2014 at 10:36 AM, Felix Fietkau wrote: >> On 2014-03-11 10:28, Helmut Schaa wrote: >>> On Sat, Feb 22, 2014 at 1:48 PM, Felix Fietkau wrote: >>>> When passing tx frames to the U-APSD queue for powersave poll responses, >>>> the ath_atx_tid pointer needs to be passed to ath_tx_setup_buffer for >>>> proper sequence number accounting. >>>> >>>> This fixes high latency and connection stability issues with ath9k >>>> running as AP and a few kinds of mobile phones as client, when PS-Poll >>>> is heavily used >>>> >>>> Cc: stable@vger.kernel.org >>>> Signed-off-by: Felix Fietkau >>>> --- >>> >>> Hi Felix, >>> >>> this commit introduced a regression for me when using Intel Win7 >>> clients on a ath9k AP. >>> >>> I was not able to track the exact issue down yet :( but it seems to be >>> related to the Intel >>> client constantly tearing down the BA session and entering/leaving PS mode. >>> >>> Any idea? >> Please make some packet captures and describe more clearly what the >> regression is. Do you see connections stalling, big latencies, etc? > > From what I can see with this patch action frames (like ADDBA and DELBA) get > sequence numbers from TID 0 assigned instead of a seq number from the global > counter. And that seems to "confuse" the client. > > The following patch solves the issue for me and seems to still keep > Felix original intention ... Looks good to me, also because it ensures that action/mgmt frames are sent out faster, even with filled data queues. To really make sure that this issue does not happen again, we should also have a check in ath_tx_setup_buffer where it actually assigns the seqno. This will become useful in case we need to buffer non-data packets (e.g. for things like P2P powersave). - Felix