Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp4204613ybg; Mon, 21 Oct 2019 05:31:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqxW6nddcleqs4/rxNBeflsrFBSmMJKUvPJkaRC5buW5oRwC8qFNfqdFvPhaek4kZTwlTHmG X-Received: by 2002:a17:906:d8c3:: with SMTP id re3mr21741522ejb.167.1571661116619; Mon, 21 Oct 2019 05:31:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571661116; cv=none; d=google.com; s=arc-20160816; b=EixIrMcE0ipxMhWkqUopbUh5dvg/MqL7DT7XmgmUQ/dJQ2ldyohpAe6oxUX6vyQwzh exAaQbYfAzZ6JivNTtitjp+eY7DQxHGMsgpkF+XdNxSduDZyV7KSs7ajb+dEqoLA/xH4 ZRufd2/KzAm4qOajPxqQfHuSuZXoxhJxw2qDOma2CiXQRP0HeoXejPkbyfAAHlirg8aU qlKZmArzsp0HK3ESl+MTX1qIMKlKS5f3TuLmrf9IlWSXyBDZ94wiX6y3nOGlgdZeHb0r gZlfXhhM3cjPx7eiQOB29CgIT5pQUGDKO4fdTXgAPEMPNgdPqoTjV1at+NjIwauu7y6V /oAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from; bh=mLFIIsO+sskaqpPSEo723e83AVmsSSXGvQB7zY8MwNw=; b=ZxzVk5e8WJIkJ9eJig9nBxEVhMEM86Y0/MoWOTXvtSCWROx+Ip599HFswYhaFgwvLS nsTi/siyH6EH9Ri5PijE08fzQU2obe1DX0vlbPFLC+uUnj3Duy3xxaqOy9j2BzYRBNl+ JX0gdreNXDCp++oyunW9w93bnemCKi2Si5aq6hnxEDkwJLiMEtqXP6tk6//GTPls4+/t gA/KSky7twm/lOVm+ORrR4bGGG9LSxSKUcpZUOGTpgeKMcKvj6Fg+It74JCAN4kATLWi uvt7PSGaT7CpZ38pvE3dIKfO7MGYNslveeMIjMa0hoQrNWLhe0v6bUeA10+rc9t98cIL gW9A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id op27si8475030ejb.253.2019.10.21.05.31.32; Mon, 21 Oct 2019 05:31:56 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728720AbfJUM3D (ORCPT + 99 others); Mon, 21 Oct 2019 08:29:03 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:4697 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727985AbfJUM3C (ORCPT ); Mon, 21 Oct 2019 08:29:02 -0400 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 54A23144C352E7C2A96E; Mon, 21 Oct 2019 20:28:58 +0800 (CST) Received: from localhost.localdomain (10.69.192.58) by DGGEMS413-HUB.china.huawei.com (10.3.19.213) with Microsoft SMTP Server id 14.3.439.0; Mon, 21 Oct 2019 20:28:54 +0800 From: Yunsheng Lin To: CC: , , , , , , , Subject: [PATCH RFC] net: vlan: reverse 4 bytes of vlan header when setting initial MTU Date: Mon, 21 Oct 2019 20:26:03 +0800 Message-ID: <1571660763-117936-1-git-send-email-linyunsheng@huawei.com> X-Mailer: git-send-email 2.8.1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.69.192.58] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 --- net/8021q/vlan.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c index 54728d2..0c26b92 100644 --- a/net/8021q/vlan.c +++ b/net/8021q/vlan.c @@ -261,10 +261,9 @@ static int register_vlan_device(struct net_device *real_dev, u16 vlan_id) return -ENOBUFS; dev_net_set(new_dev, net); - /* need 4 bytes for extra VLAN header info, - * hope the underlying device can handle it. - */ - new_dev->mtu = real_dev->mtu; + new_dev->mtu = real_dev->mtu - VLAN_HLEN; + if (new_dev->mtu < ETH_MIN_MTU) + new_dev->mtu = ETH_MIN_MTU; vlan = vlan_dev_priv(new_dev); vlan->vlan_proto = htons(ETH_P_8021Q); -- 2.8.1