Re: [PATCH net-next] ip6_gre: Fix MTU setting

Tom Herbert
2016-05-09T23:47:11Z

On Mon, May 9, 2016 at 4:10 PM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Mon, May 9, 2016 at 3:49 PM, Tom Herbert <tom@herbertland.com> wrote:
>> On Mon, May 9, 2016 at 3:44 PM, Alexander Duyck
>> <alexander.duyck@gmail.com> wrote:
>>> On Mon, May 9, 2016 at 3:28 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>> In ip6gre_tnl_link_config set t->tun_len and t->hlen correctly for the
>>>> configuration. For hard_header_len and mtu calculation include
>>>> IPv6 header and encapsulation overhead.
>>>>
>>>> In ip6gre_tunnel_init_common set t->tun_len and t->hlen correctly for
>>>> the configuration. Revert to setting hard_header_len instead of
>>>> needed_headroom.
>>>>
>>>> Tested:
>>>>
>>>> ./ip link add name tun8 type ip6gretap remote \
>>>> 2401:db00:20:911a:face:0:27:0 local \
>>>> 2401:db00:20:911a:face:0:25:0 ttl 225
>>>>
>>>> Gives MTU of 1434. That is equal to 1500 - 40 - 14 - 4 - 8.
>>>>
>>>> ./ip link add name tun8 type ip6gretap remote \
>>>> 2401:db00:20:911a:face:0:27:0 local \
>>>> 2401:db00:20:911a:face:0:25:0 ttl 225 okey 123
>>>>
>>>> Gives MTU of 1430. That is equal to 1500 - 40 - 14 - 4 - 8 - 4.
>>>>
>>>> Signed-off-by: Tom Herbert <tom@herbertland.com>
>>>
>>> So this gives me the correct result now. However we still need patch
>>> 3 / 11 from the set you submitted next week in order to be able to
>>> even transmit because the flags are otherwise mangled.
>>>
>>> Tested-by: Alexander Duyck <aduyck@mirantis.com>
>>
>> Okay, I'll repost the flags patch as a standalone. Do you have any
>> other issues then in this path?
>
> This piece no.
>
> Like I said in the other email I did find two other issues. First in
> __gre6_xmit I think you want to set the inner protocol to "protocol",
> not "proto". Second is the issue with ip6_tnl_xmit stomping on
> skb->transport_header. The second one is the big one that is blocking
> things badly right now. That is the one that keeps me from doing
> anything with any sort of offload as the headers are jumping around
> out of order with the outer transport header having an offset that is
> further in than the inner mac header.
>
You mean "skb->transport_header = skb->network_header;"? It doesn't
look right to me either, but that line has been around a while....

> I'd be fine with you submitting the whole set as one piece with the
> other 11 patches you had just as long as we get those core pieces
> fixed in the patch set.
>
Probably just as easy to break it up.

> - Alex