Re: [PATCH] net: Fragment large datagrams even when IP_HDRINCL is set.

[Senthil Kumar Nagappan <nagappanksenthil@gmail.com>]

On 7/12/2016 11:41 PM, David Miller wrote:
> From: Alan Davey <Alan.Davey@metaswitch.com>
> Date: Tue, 12 Jul 2016 12:34:07 +0000
>
>> -  all future applications have to continue to implement their own fragmentation code, duplicating that which already exists in the kernel
> They have to do this anyways, don't you see this?
>
> Otherwise they don't support %99 of the kernels out there.
>
> Even if I put this change in now, it would take years for it to
> propagate to even a moderate percentage of Linux machines out there.
>
> And applications doing a "we only support kernels > version x.y.z" is
> a situation I don't want to promote if you think that's a reasonable
> way to handle this.
>
> Dave patch functionality is good to have in the kernel.
> The reason David says it not convincing,  since its there for decades and "we only support kernels > version x.y.z", As Paul suggested we could have a socket option to avoid compatibility issues.
>
> Dave patch has minimal changes, but i see some downsides to it and suggestion to do this differently.
> 1. We will not be able to support MSG_MORE if we take this path.
> 2. we will try to allocate one big skb based on the user data size and kmalloc might fail to allocate a big contiguous buffer, which is not better as compared to the path taken using ip_append_data where we will take care allocating skb's based on the mtu.
> 3. other suggestion is, may be we can take the ip_append_data path, some were down the line we can use the user provided header.