netdev - Re: [PATCH net] vxlan: update skb dst pmtu on tx path

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20171219.111207.1046172818461753483.davem@davemloft.net>
Date:   Tue, 19 Dec 2017 11:12:07 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     lucien.xin@...il.com
Cc:     netdev@...r.kernel.org, jbenc@...hat.com
Subject: Re: [PATCH net] vxlan: update skb dst pmtu on tx path

From: Xin Long <lucien.xin@...il.com>
Date: Mon, 18 Dec 2017 14:20:56 +0800

> Unlike ip tunnels, now vxlan doesn't do any pmtu update for
> upper dst pmtu, even if it doesn't match the lower dst pmtu
> any more.
> 
> The problem can be reproduced when reducing the vxlan lower
> dev's pmtu when running netperf. In jianlin's testing, the
> performance went to 1/7 of the previous.
> 
> This patch is to update the upper dst pmtu to match the lower
> dst pmtu on tx path so that packets can be sent out even when
> lower dev's pmtu has been changed.
> 
> It also works for metadata dst.
> 
> Note that this patch doesn't process any pmtu icmp packet.
> But even in the future, the support for pmtu icmp packets
> process of udp tunnels will also needs this.
> 
> The same thing will be done for geneve in another patch.
> 
> Signed-off-by: Xin Long <lucien.xin@...il.com>

Yikes...

You're going to have to find a way to fix this without
invoking ->update_pmtu() on every single transmit.  That's
really excessive, especially for an operation which is
going to be a NOP %99.9999 of the time.

We need some way, instead, for the MTU change event to propagate
properly.  I know this might be hard, but doing this in the transmit
handler on every packet to deal with it is not the way to go.

Thanks.