[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <0E7BC212-3BBA-4C68-89B9-C6DA956553AD@yandex-team.ru>
Date: Wed, 28 Oct 2020 00:44:57 +0300
From: Alexander Ovechkin <ovov@...dex-team.ru>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>,
vfedorenko@...ek.ru
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH net] ip6_tunnel: set inner ipproto before ip6_tnl_encap.
> But it was moved on purpose to avoid setting the inner protocol to IPPROTO_MPLS. That needs to use skb->inner_protocol to further segment.
And why do we need to avoid setting the inner protocol to IPPROTO_MPLS? Currently skb->inner_protocol is used before call of ip6_tnl_xmit.
Can you please give example when this patch breaks MPLS segmentation?
> On 16 Oct 2020, at 20:55, Willem de Bruijn <willemdebruijn.kernel@...il.com> wrote:
>
> On Fri, Oct 16, 2020 at 7:14 AM Alexander Ovechkin <ovov@...dex-team.ru> wrote:
>>
>> ip6_tnl_encap assigns to proto transport protocol which
>> encapsulates inner packet, but we must pass to set_inner_ipproto
>> protocol of that inner packet.
>>
>> Calling set_inner_ipproto after ip6_tnl_encap might break gso.
>> For example, in case of encapsulating ipv6 packet in fou6 packet, inner_ipproto
>> would be set to IPPROTO_UDP instead of IPPROTO_IPV6. This would lead to
>> incorrect calling sequence of gso functions:
>> ipv6_gso_segment -> udp6_ufo_fragment -> skb_udp_tunnel_segment -> udp6_ufo_fragment
>> instead of:
>> ipv6_gso_segment -> udp6_ufo_fragment -> skb_udp_tunnel_segment -> ip6ip6_gso_segment
>>
>> Signed-off-by: Alexander Ovechkin <ovov@...dex-team.ru>
>
> Commit 6c11fbf97e69 ("ip6_tunnel: add MPLS transmit support") moved
> the call from ip6_tnl_encap's caller to inside ip6_tnl_encap.
>
> It makes sense that that likely broke this behavior for UDP (L4) tunnels.
>
> But it was moved on purpose to avoid setting the inner protocol to
> IPPROTO_MPLS. That needs to use skb->inner_protocol to further
> segment.
>
> I suspect we need to set this before or after conditionally to avoid
> breaking that use case.
Powered by blists - more mailing lists