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 6C61A3B260 for ; Thu, 1 Sep 2016 14:31:04 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Filter: OpenDKIM Filter v2.10.3 mail2.tohojo.dk 3154D4161D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1472754661; bh=Rna+IgJ0mkeQPOeJPrQJ77wpNv3km84eD7TSyU++myM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Hw2mSNpQhxyA68dCco3gcojCspHiblP/WY2rZ/jEUqpSmbEjPjP4ytYwZ5wNtvcYg f3wd0enprjSvAVhGBWLByrLK4vTdCqhFrcNb/zfvvbg2qHMad2nnS8jswCbE1ZAR2w yTAz6wCHxW+b7GJFQvUAmIrhTaRjxqMQEIj9PlYw= Sender: toke@toke.dk Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id DFDB2C40238; Thu, 1 Sep 2016 20:30:59 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Johannes Berg Cc: make-wifi-fast@lists.bufferbloat.net, linux-wireless@vger.kernel.org References: <20160830131548.6014-1-toke@toke.dk> <20160901160312.31540-1-toke@toke.dk> <1472752745.9608.8.camel@sipsolutions.net> Date: Thu, 01 Sep 2016 20:30:59 +0200 In-Reply-To: <1472752745.9608.8.camel@sipsolutions.net> (Johannes Berg's message of "Thu, 01 Sep 2016 19:59:05 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <871t1379r0.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 18:31:04 -0000 Johannes Berg writes: >> 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. Hmm, guess that makes sense. Bugger. Will think about how to do that. > > 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? (assuming the last line was supposed to read 'seq=1,frag=1') Yes, that could happen, in principle (it depends on the fragments' size in relation to the FQ quantum). When does fragmentation happen anyway? Is it safe to assume there's no aggregation when it does? -Toke