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 5566B3B25E for ; Mon, 5 Sep 2016 13:59:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Filter: OpenDKIM Filter v2.10.3 mail2.tohojo.dk D713B4161D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1473098347; bh=pIb3f9iYuApE+uCC/NH/vrwGmQp1gwjMud/B7leUo24=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=uoL+a7Q04jxyw9xF8p6TGbwuyJu9WV4B/scvNieGrtVcR4pbPhswmgadooxHqNf93 Mj+vG0IzEp4V1cFgxWR7G9AnJ9tsWijbZVRidhFMNVM0wIa3o0bp1VdNQIkj5t6F4M GhWDe0dDZJPrSUDRwuFZ+ZUake4DzSxGhwHOR7pY= Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 0D0047931; Mon, 5 Sep 2016 19:59:07 +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 References: <20160902134104.29309-1-toke@toke.dk> <20160905113042.22271-1-toke@toke.dk> <8ffb5fee-78c1-79aa-2297-e125c59b092c@nbd.name> Date: Mon, 05 Sep 2016 19:59:06 +0200 In-Reply-To: <8ffb5fee-78c1-79aa-2297-e125c59b092c@nbd.name> (Felix Fietkau's message of "Mon, 5 Sep 2016 19:49:42 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87wpiq9qj9.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [PATCH v7] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue. 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: Mon, 05 Sep 2016 17:59:10 -0000 Felix Fietkau writes: > On 2016-09-05 13:30, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> The TXQ intermediate queues can cause packet reordering when more than >> one flow is active to a single station. Since some of the wifi-specific >> packet handling (notably sequence number and encryption handling) is >> sensitive to re-ordering, things break if they are applied before the >> TXQ. >>=20 >> This splits up the TX handlers and fast_xmit logic into two parts: An >> early part and a late part. The former is applied before TXQ enqueue, >> and the latter after dequeue. The non-TXQ path just applies both parts >> at once. >>=20 >> Because fragments shouldn't be split up or reordered, the fragmentation >> handler is run after dequeue. Any fragments are then kept in the TXQ and >> on subsequent dequeues they take precedence over dequeueing from the FQ >> structure. >>=20 >> This approach avoids having to scatter special cases for when TXQ is >> enabled, at the cost of making the fast_xmit and TX handler code >> slightly more complex. > In my test, this one completely breaks ath9k with the txq patch. > One or two packets go through, then tx stalls completely. I assume you are testing on LEDE? It requires a change to work with the patch in the LEDE tree that puts hdrlen into ieee80211_tx_data. Did you fix that? Otherwise multicast (and possibly other things) will break badly. I have a version that should work with LEDE here: https://kau.toke.dk/git/lede/tree/package/kernel/mac80211/patches/346-mac80= 211-move-reorder-sensitive-tx-handlers-to-after-TXQ-dequeue.patch -Toke