On Fri, Jan 11, 2019 at 10:10 AM Michal Kubecek <mkube...@suse.cz> wrote: > > On Friday, 11 January 2019 18:09 Peter Oskolkov wrote: > > On Fri, Jan 11, 2019 at 6:54 AM Timothy Winters <twint...@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 > >
