* [PATCH RFC] net: vlan: reverse 4 bytes of vlan header when setting initial MTU
@ 2019-10-21 12:26 Yunsheng Lin
2019-10-21 14:46 ` David Laight
2019-10-21 23:27 ` Stephen Hemminger
0 siblings, 2 replies; 6+ messages in thread
From: Yunsheng Lin @ 2019-10-21 12:26 UTC (permalink / raw)
To: davem
Cc: dsahern, jiri, allison, mmanning, petrm, dcaratti, netdev, linux-kernel
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>
---
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
^ permalink raw reply related [flat|nested] 6+ messages in thread
* RE: [PATCH RFC] net: vlan: reverse 4 bytes of vlan header when setting initial MTU
2019-10-21 12:26 [PATCH RFC] net: vlan: reverse 4 bytes of vlan header when setting initial MTU Yunsheng Lin
@ 2019-10-21 14:46 ` David Laight
2019-10-22 1:28 ` Yunsheng Lin
2019-10-21 23:27 ` Stephen Hemminger
1 sibling, 1 reply; 6+ messages in thread
From: David Laight @ 2019-10-21 14:46 UTC (permalink / raw)
To: 'Yunsheng Lin', davem
Cc: dsahern, jiri, allison, mmanning, petrm, dcaratti, netdev, linux-kernel
From: Yunsheng Lin
> Sent: 21 October 2019 13:26
> 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.
s/reverse/reserve/g
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH RFC] net: vlan: reverse 4 bytes of vlan header when setting initial MTU
2019-10-21 14:46 ` David Laight
@ 2019-10-22 1:28 ` Yunsheng Lin
0 siblings, 0 replies; 6+ messages in thread
From: Yunsheng Lin @ 2019-10-22 1:28 UTC (permalink / raw)
To: David Laight, davem
Cc: dsahern, jiri, allison, mmanning, petrm, dcaratti, netdev, linux-kernel
On 2019/10/21 22:46, David Laight wrote:
> From: Yunsheng Lin
>> Sent: 21 October 2019 13:26
>> 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.
>
> s/reverse/reserve/g
Thanks.
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
>
>
> .
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH RFC] net: vlan: reverse 4 bytes of vlan header when setting initial MTU
2019-10-21 12:26 [PATCH RFC] net: vlan: reverse 4 bytes of vlan header when setting initial MTU Yunsheng Lin
2019-10-21 14:46 ` David Laight
@ 2019-10-21 23:27 ` Stephen Hemminger
2019-10-22 1:31 ` Yunsheng Lin
1 sibling, 1 reply; 6+ messages in thread
From: Stephen Hemminger @ 2019-10-21 23:27 UTC (permalink / raw)
To: Yunsheng Lin
Cc: davem, dsahern, jiri, allison, mmanning, petrm, dcaratti, netdev,
linux-kernel
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH RFC] net: vlan: reverse 4 bytes of vlan header when setting initial MTU
2019-10-21 23:27 ` Stephen Hemminger
@ 2019-10-22 1:31 ` Yunsheng Lin
2019-10-22 2:47 ` David Ahern
0 siblings, 1 reply; 6+ messages in thread
From: Yunsheng Lin @ 2019-10-22 1:31 UTC (permalink / raw)
To: Stephen Hemminger
Cc: davem, dsahern, jiri, allison, mmanning, petrm, dcaratti, netdev,
linux-kernel
On 2019/10/22 7:27, Stephen Hemminger wrote:
> 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.
Ok.
Is there any other feasible way to bring back the performance gain in the
vlan netdev over vxlan netdev case?
Or we just leave it as it is, and expect user to manually configure the MTU
of vlan netdev to the MTU of thelower device minus vlan header when the
performace in the above case is a concern to user?
Thanks.
>
>
> .
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH RFC] net: vlan: reverse 4 bytes of vlan header when setting initial MTU
2019-10-22 1:31 ` Yunsheng Lin
@ 2019-10-22 2:47 ` David Ahern
0 siblings, 0 replies; 6+ messages in thread
From: David Ahern @ 2019-10-22 2:47 UTC (permalink / raw)
To: Yunsheng Lin, Stephen Hemminger
Cc: davem, jiri, allison, mmanning, petrm, dcaratti, netdev, linux-kernel
On 10/21/19 7:31 PM, Yunsheng Lin wrote:
> Or we just leave it as it is, and expect user to manually configure the MTU
> of vlan netdev to the MTU of thelower device minus vlan header when the
> performace in the above case is a concern to user?
>
for now, I would think so. vlan on a vxlan device ... you are going
after q-in-q'ish with vxlan? that can not be a common deployment.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-10-22 2:47 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-21 12:26 [PATCH RFC] net: vlan: reverse 4 bytes of vlan header when setting initial MTU Yunsheng Lin
2019-10-21 14:46 ` David Laight
2019-10-22 1:28 ` Yunsheng Lin
2019-10-21 23:27 ` Stephen Hemminger
2019-10-22 1:31 ` Yunsheng Lin
2019-10-22 2:47 ` David Ahern
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.