From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <johannes@sipsolutions.net>
Received: from sipsolutions.net (s3.sipsolutions.net [5.9.151.49])
 (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 2CCDE3B260
 for <make-wifi-fast@lists.bufferbloat.net>;
 Thu,  1 Sep 2016 13:59:08 -0400 (EDT)
Received: by sipsolutions.net with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87)
 (envelope-from <johannes@sipsolutions.net>)
 id 1bfWGY-0003yc-Ct; Thu, 01 Sep 2016 19:59:06 +0200
Message-ID: <1472752745.9608.8.camel@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= <toke@toke.dk>, 
 make-wifi-fast@lists.bufferbloat.net, linux-wireless@vger.kernel.org
Date: Thu, 01 Sep 2016 19:59:05 +0200
In-Reply-To: <20160901160312.31540-1-toke@toke.dk>
 (sfid-20160901_180539_629379_96553E29)
References: <20160830131548.6014-1-toke@toke.dk>
 <20160901160312.31540-1-toke@toke.dk>
 (sfid-20160901_180539_629379_96553E29)
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.20.4-1+b1 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [Make-wifi-fast] [PATCH v5] 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: <make-wifi-fast.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/make-wifi-fast>,
 <mailto:make-wifi-fast-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/make-wifi-fast>
List-Post: <mailto:make-wifi-fast@lists.bufferbloat.net>
List-Help: <mailto:make-wifi-fast-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/make-wifi-fast>,
 <mailto:make-wifi-fast-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Thu, 01 Sep 2016 17:59:08 -0000


> To avoid having to deal with fragmentation on dequeue, the split is
> set to be after the fragmentation handler. This means that some
> reordering of TX handlers is necessary, and some handlers had to be
> made aware of fragmentation due to this reordering.

Come to think of it, that's actually counterproductive.

If a fragment is dropped, or even just if fragments are reordered, the
receiver will not be able to defragment the frame, and will thus drop
it. Therefore, it's all-or-nothing, and we shouldn't transmit any
fragment if we drop/reorder one (*).

So ... I think you'll just have to deal with fragmentation on the
codel/fq/whatever queues and keep fragments together, or do
fragmentation afterwards.

johannes


(*) also, couldn't this mean that we send something completely stupid
like

seq=1,frag=0
seq=2,frag=0
seq=2,frag=1
seq=2,frag=1

if reordering happened?