Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 21 Oct 2019 16:27:51 -0700
From:   Stephen Hemminger <stephen@networkplumber.org>
To:     Yunsheng Lin <linyunsheng@huawei.com>
Cc:     <davem@davemloft.net>, <dsahern@gmail.com>, <jiri@mellanox.com>,
        <allison@lohutok.net>, <mmanning@vyatta.att-mail.com>,
        <petrm@mellanox.com>, <dcaratti@redhat.com>,
        <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC] net: vlan: reverse 4 bytes of vlan header when
 setting initial MTU
Message-ID: <20191021162751.1ccb251e@hermes.lan>
In-Reply-To: <1571660763-117936-1-git-send-email-linyunsheng@huawei.com>
References: <1571660763-117936-1-git-send-email-linyunsheng@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, 21 Oct 2019 20:26:03 +0800
Yunsheng Lin <linyunsheng@huawei.com> wrote:

> Currently the MTU of vlan netdevice is set to the same MTU
> of the lower device, which requires the underlying device
> to handle it as the comment has indicated:
> 
> 	/* need 4 bytes for extra VLAN header info,
> 	 * hope the underlying device can handle it.
> 	 */
> 	new_dev->mtu = real_dev->mtu;
> 
> Currently most of the physical netdevs seems to handle above
> by reversing 2 * VLAN_HLEN for L2 packet len.
> 
> But for vlan netdev over vxlan netdev case, the vxlan does not
> seems to reverse the vlan header for vlan device, which may cause
> performance degradation because vxlan may emit a packet that
> exceed the MTU of the physical netdev, and cause the software
> TSO to happen in ip_finish_output_gso(), software TSO call stack
> as below:
> 
>  => ftrace_graph_call
>  => tcp_gso_segment
>  => tcp4_gso_segment
>  => inet_gso_segment
>  => skb_mac_gso_segment
>  => skb_udp_tunnel_segment
>  => udp4_ufo_fragment
>  => inet_gso_segment
>  => skb_mac_gso_segment
>  => __skb_gso_segment
>  => __ip_finish_output
>  => ip_output
>  => ip_local_out
>  => iptunnel_xmit
>  => udp_tunnel_xmit_skb
>  => vxlan_xmit_one
>  => vxlan_xmit
>  => dev_hard_start_xmit
>  => __dev_queue_xmit
>  => dev_queue_xmit
>  => vlan_dev_hard_start_xmit
>  => dev_hard_start_xmit
>  => __dev_queue_xmit
>  => dev_queue_xmit
>  => neigh_resolve_output
>  => ip_finish_output2
>  => __ip_finish_output
>  => ip_output
>  => ip_local_out
>  => __ip_queue_xmit
>  => ip_queue_xmit
>  => __tcp_transmit_skb
>  => tcp_write_xmit
>  => __tcp_push_pending_frames
>  => tcp_push
>  => tcp_sendmsg_locked
>  => tcp_sendmsg
>  => inet_sendmsg
>  => sock_sendmsg
>  => sock_write_iter
>  => new_sync_write
>  => __vfs_write
>  => vfs_write
>  => ksys_write
>  => __arm64_sys_write
>  => el0_svc_common.constprop.0
>  => el0_svc_handler
>  => el0_svc  
> 
> This patch set initial MTU of the vlan device to the MTU of the
> lower device minus vlan header to handle the above case.
> 
> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>

The MTU is visible to user space in many tools, and Linux (and BSD)
have always treated VLAN header as not part of the MTU. You can't change
that now.