[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <65961d37-9f7f-631c-2293-aa1193aca83b@novek.ru>
Date: Sat, 26 Jun 2021 22:41:21 +0100
From: Vadim Fedorenko <vfedorenko@...ek.ru>
To: David Ahern <dsahern@...il.com>, David Ahern <dsahern@...nel.org>,
netdev@...r.kernel.org, Roopa Prabhu <roopa@...dia.com>
Cc: Jakub Kicinski <kuba@...nel.org>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net v2] net: lwtunnel: handle MTU calculation in forwading
On 26.06.2021 18:18, David Ahern wrote:
> [ added Roopa's nvidia address ]
>
> On 6/25/21 10:21 AM, Vadim Fedorenko wrote:
>> Commit 14972cbd34ff ("net: lwtunnel: Handle fragmentation") moved
>> fragmentation logic away from lwtunnel by carry encap headroom and
>> use it in output MTU calculation. But the forwarding part was not
>> covered and created difference in MTU for output and forwarding and
>> further to silent drops on ipv4 forwarding path. Fix it by taking
>> into account lwtunnel encap headroom.
>>
>> The same commit also introduced difference in how to treat RTAX_MTU
>> in IPv4 and IPv6 where latter explicitly removes lwtunnel encap
>> headroom from route MTU. Make IPv4 version do the same.
>>
>> Fixes: 14972cbd34ff ("net: lwtunnel: Handle fragmentation")
>> Suggested-by: David Ahern <dsahern@...il.com>
>> Signed-off-by: Vadim Fedorenko <vfedorenko@...ek.ru>
>> ---
>> include/net/ip.h | 12 ++++++++----
>> include/net/ip6_route.h | 16 ++++++++++++----
>> net/ipv4/route.c | 3 ++-
>> 3 files changed, 22 insertions(+), 9 deletions(-)
>>
>
>
> I think this is the right approach - tunnel overhead should always be
> considered for the mtu. Did you run the pmtu.sh selftests to make sure
> those still work?
>
Actually not, I was running my own tests of routing configurations with
different types of tunnels like GRE, GUE and FOU with mpls lwtunnels to check
consistency of calculated mtus.
Will re-run pmtu.sh but I my installation doesn't support OVS right now.
Also, I was thinking about this RTAX_MTU and I'm really in doubt. Do we actually
want the situation when
ip route A.B.C.D/32 encap mpls 100 dev ip6tnl1 mtu 1400
will actually require mtu=1396? Because this looks like not clear for users I
suppose.
Powered by blists - more mailing lists