>> On Wed, 15 Jun 2016, Alan Davey wrote: >> >>> The only case that would break is that where an application relies on >>> the existing (documented as a bug) feature of getting an EMSGSIZE >>> return code in the case of an over-sized packet. Applications that >>> perform their own fragmentation would be unaffected. >> >> If this doesn't break existing applications that are doing >> fragmentation in userspace on raw sockets (e.g. Quagga ospfd), that's >> better. >> >> As per previous email, I'd love to be able to get rid of that code and >> have the kernel do it for me. However, I also don't want to have to do >> anything other non-trivial to that code either. :) >> >> The issue for us is, how would we know on any given host whether the >> kernel will do the fragmentation or whether ospfd has to do it? We >> need to be able to probe for that capability, surely? > >The fact is, regardless of whether you could probe for the capability or not, >you have to keep the fragmentation code around forever. > >And that is yet another reason I do not want to add this change at all. > >It doesn't make any existing server any simpler, in fact it makes them all >more complicated because not only do they keep the fragmentation code, they >also >get new logic to test for the feature that would allow them to avoid >using it. > >Sorry, there is no way I am adding this, it's a net lose.
David, I accept you don't want to take this patch. However, I don't yet understand why, so I have a few more questions (which will hopefully help me produce patches that are likely to be accepted in future). Adding the patch means that some existing applications will continue to contain their own fragmentation code, which becomes unnecessary. This is OK; those applications will continue to fragment packets, and will continue to work with an updated kernel. Do you agree? Not adding the patch means that - all future applications have to continue to implement their own fragmentation code, duplicating that which already exists in the kernel - hardware vendors may choose to apply the patch themselves (they do not want to implement function that already exists), but would surely prefer to have it in the standard kernel. So I still don't understand what part of taking the patch would have a negative result on existing applications, it should be neutral to them. Could you help me out here and explain? Regards Alan
