Return-path: Received: from mail-wi0-f178.google.com ([209.85.212.178]:37609 "EHLO mail-wi0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932335Ab2FIASe (ORCPT ); Fri, 8 Jun 2012 20:18:34 -0400 Received: by wibhn6 with SMTP id hn6so1045987wib.1 for ; Fri, 08 Jun 2012 17:18:33 -0700 (PDT) From: Christian Lamparter To: Sean Patrick Santos Subject: Re: BA session issue due to old BARs? Date: Sat, 9 Jun 2012 02:18:27 +0200 Cc: linux-wireless@vger.kernel.org, nbd@openwrt.org, helmut.schaa@googlemail.com References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Message-Id: <201206090218.27603.chunkeey@googlemail.com> (sfid-20120609_021838_203461_E832B3B9) Sender: linux-wireless-owner@vger.kernel.org List-ID: On Friday 08 June 2012 09:57:26 Sean Patrick Santos wrote: > I believe that I have found the commit that introduced this problem, > which was a change in mac80211. However, I'm out of my depth in > figuring out what a really "correct" solution is; all I've done is a > trial-and-error bisection. The commit in question: > > commit f0425beda4d404a6e751439b562100b902ba9c98 > Author: Felix Fietkau > Date: Sun Aug 28 21:11:01 2011 +0200 > > mac80211: retry sending failed BAR frames later instead of tearing down aggr > > Unfortunately failed BAR tx attempts happen more frequently than I > expected, and the resulting aggregation teardowns cause performance > issues, as the aggregation session does not always get re-established > properly. > Instead of tearing down the entire aggr session, we can simply store the > SSN of the last failed BAR tx attempt, wait for the first successful > tx status event, and then send another BAR with the same SSN. > > Signed-off-by: Felix Fietkau > Cc: Helmut Schaa > Signed-off-by: John W. Linville > > This looks relevant. As a matter of personal convenience, I might try > backing out the change tomorrow if it seems that it'll help. Felix, is there any way we can restore the old behavior of tearing down BAs due to BAR transmission failures without breaking ath9k (or rt2x00)? Or am I misinterpreting the commit and this patch was just a temporary fix since back then mac80211 had problems with setting up BA session (and they might have been fixed in the meantime?!). Quote from the first paragraph of the commit: > ... the resulting aggregation teardowns cause performance > issues, as the aggregation session does not always get > re-established properly. Regards, Christian