From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (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 A533D3B260 for ; Wed, 17 Aug 2016 08:04:04 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Filter: OpenDKIM Filter v2.10.3 mail2.tohojo.dk 47F4740D5E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1471435442; bh=ZQdpSCBPS171Yu+3gze9WQvMdc0mBvBrbxIgaEnjpwE=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=qtkuCAnceLJUfRGEV5fu40z5Uhc+R1UAPaPsk3TINEyZiWz2Gsc4NTcEFhMRlDgrX zEgqxOeeD3C0j7/gXJSsVF9IrdkDAPp/fNV8dmDasPlfJUjkxUhuJwtC9cxYh9iQ2W mCNPD2M/+xh7I0QFILb3ekhurJKhL3wPhqSgeuZA= Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 334695F57; Wed, 17 Aug 2016 14:04:01 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Felix Fietkau Cc: make-wifi-fast@lists.bufferbloat.net, linux-wireless@vger.kernel.org, Michal Kazior , Dave Taht References: <87pop85tvr.fsf@toke.dk> <6d471495-fa0f-f750-a4a4-f467205b94bd@nbd.name> Date: Wed, 17 Aug 2016 14:04:01 +0200 In-Reply-To: <6d471495-fa0f-f750-a4a4-f467205b94bd@nbd.name> (Felix Fietkau's message of "Wed, 17 Aug 2016 06:18:09 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87lgzv61qm.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Make-wifi-fast] On the ath9k performance regression with FQ and crypto 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: Wed, 17 Aug 2016 12:04:04 -0000 Felix Fietkau writes: > I have not done any further tests, but based on your analysis, I think I > finally understand what's causing this issue: > The CCMP PN (crypto IV) is assigned in the tx path before a packet is > put into the txq. It is also used to protect against replay attacks, so > it is sensitive to reordering. The receiver is simply dropping any > packet where the PN value is lower than the highest PN received so far. > To fix this, we will have to move the IV/PN assignment to > ieee80211_tx_dequeue. Indeed this seems to be the cause of the problem. Thanks! Will send a patch once we've run it through another couple rounds of testing. Looks promising so far :) -Toke