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 777BD3B25D for ; Tue, 6 Sep 2016 07:45:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Filter: OpenDKIM Filter v2.10.3 mail2.tohojo.dk 25B1D40D5E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1473162328; bh=L+keU/6hbkB/1SKDx3ypPjCAYlOiKcs1S3L1/yzOapI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=WwDCHj699zRSnPWAgHCU6D/hqCjd2TG0QQhnr8PswTZ0CFuG75fLWqwwIx2QjhDrZ PQR3tPkK3HgWYcdLPFMibqfZ79Id67nGAttQabb2MisKbIC3i5hEAWCh7O1wzOsMqZ bUFrSmbqIdII8MK7Y0MggLmTKiFbNIx6yQQpXKSE= Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id 8768EC40236; Tue, 6 Sep 2016 13:45:27 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: make-wifi-fast@lists.bufferbloat.net Cc: linux-wireless@vger.kernel.org References: <20160905113042.22271-1-toke@toke.dk> <20160906114311.24522-1-toke@toke.dk> Date: Tue, 06 Sep 2016 13:45:27 +0200 In-Reply-To: <20160906114311.24522-1-toke@toke.dk> ("Toke =?utf-8?Q?H?= =?utf-8?Q?=C3=B8iland-J=C3=B8rgensen=22's?= message of "Tue, 6 Sep 2016 13:43:11 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87k2ep45go.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: Tue, 06 Sep 2016 11:45:29 -0000 Toke H=C3=B8iland-J=C3=B8rgensen writes: > 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. > > 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. > > 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. > > 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. > > Signed-off-by: Toke H=C3=B8iland-J=C3=B8rgensen Sorry for sending this again; meant to send v8. :/ -Toke