From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michal Kubecek <mkubecek@suse.cz>
Subject: Re: [PATCH v3 23/30] ipv6: defrag: drop non-last frags smaller than min mtu
Date: Fri, 11 Jan 2019 19:10:39 +0100
Message-ID: <8060783.W0OyfDEgf0@alaris>
References: <20180913145902.17531-1-sthemmin@microsoft.com> <CAOSSMjVMVWxzkT5M2LHgf0+GPHdaWHV01a6mBqbGRVXOaQ04PQ@mail.gmail.com> <CAPNVh5e=VTiCfniscHrq+PafZ3FOc2p2rp=r4my9Jp9st_5HjQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: Peter Oskolkov <posk@google.com>,
        Timothy Winters <twinters@iol.unh.edu>,
        Eric Dumazet <edumazet@google.com>,
        Eric Dumazet <eric.dumazet@gmail.com>,
        Florian Westphal <fw@strlen.de>,
        Tom Herbert <tom@herbertland.com>,
        David Miller <davem@davemloft.net>
To: netdev <netdev@vger.kernel.org>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mx2.suse.de ([195.135.220.15]:55958 "EHLO mx1.suse.de"
        rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP
        id S1727745AbfAKSKl (ORCPT <rfc822;netdev@vger.kernel.org>);
        Fri, 11 Jan 2019 13:10:41 -0500
In-Reply-To: <CAPNVh5e=VTiCfniscHrq+PafZ3FOc2p2rp=r4my9Jp9st_5HjQ@mail.gmail.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Friday, 11 January 2019 18:09 Peter Oskolkov wrote:
> On Fri, Jan 11, 2019 at 6:54 AM Timothy Winters <twinters@iol.unh.edu> wrote:
> > Thanks for the clarification.   I'm thinking about creating a draft
> > to say no fragments less then 640 unless it's the last fragment.  
> > Does that work for your code going forward?
> 
> I will prepare a patchset to convert IPv6 defrag queue to rbtree+list,
> similarly to how IPv4 defrag queue currently works. Just in case it
> is decided to go this route. I don't think having an
> arbitrary/non-standard size cap (640) is a good approach.

It's not completely arbitrary. The idea is that two most obvious
fragment sizing strategies are

  (a) use maximum possible size for all except last, then the rest
  (b) calculate minimum required fragment count and use (almost) the
      same size for all of them

Both strategies create non-last fragments of size at least 1280 / 2.
But I agree that using the same data structure and algorithm as for
IPv4 is more future proof.

Michal Kubecek