Re: [PATCH v3 23/30] ipv6: defrag: drop non-last frags smaller than min mtu

Tom Herbert
2019-01-12T03:21:29Z

On Fri, Jan 11, 2019 at 10:10 AM Michal Kubecek <mkubecek@suse.cz> wrote:
>
> 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.
>
Yes, the 640 value is being discussed on 6man. I think the correct
approach might be to turn the limit into a sysctl and make the default
value 640. I'm not sure how, or if this should be applied to IPv4
though.

Tom

> Michal Kubecek
>
>