Need your help on this tricky behaviour:

we have virtual machine running with SLE12 SP5. Packets are receveid on eth0 and after GRO and tunneling they are forwarded to eth2 interface:

# Packet (1) is received on the “eth0”, GRO is invoked:
<idle>-0 [007] ..s. 171178.019023: napi_gro_receive_entry: dev=eth0 napi_id=0x2038 queue_mapping=0 skbaddr=ffff95b6e89cc800 vlan_tagged=0 vlan_proto=0x0000 vlan_tci=0x0000 protocol=0x86dd ip_summed=0 hash=0x64158e67l4_hash=0 len=152 data_len=0 truesize=2112 mac_header_valid=1 mac_header=-14 nr_frags=0 gso_size=0 gso_type=0x0
<idle>-0 [007] d.s. 171178.019024: dev_gro_receive_start: (dev_gro_receive+0x0/0x640) skb=0xffff95b6e89cc800 len=152

# Packet (2) is received on the “eth0”, GRO is invoked:
<idle>-0 [007] ..s. 171178.019027: napi_gro_receive_entry: dev=eth0 napi_id=0x2038 queue_mapping=0 skbaddr=ffff95b694f93700 vlan_tagged=0 vlan_proto=0x0000 vlan_tci=0x0000 protocol=0x86dd ip_summed=0 hash=0x64158e67l4_hash=0 len=152 data_len=0 truesize=2112 mac_header_valid=1 mac_header=-14 nr_frags=0 gso_size=0 gso_type=0x0

# This time, GRP detects (2) on the same “flow” as the previous (1), so merges the two packets (ret=0x1) and sends the merge to upper layer:
<idle>-0 [007] d.s. 171178.019028: skb_gro_receive: (skb_gro_receive+0x0/0x350) p=0xffff95b6e89cc800 p_len=152 skb=0xffff95b694f93700 len=152
<idle>-0 [007] d.s. 171178.019028: dev_gro_receive_ret: (napi_gro_receive+0x33/0xe0 <- dev_gro_receive) ret=0x1 skb=0xffff95b694f93700 len=152
<idle>-0 [007] d.s. 171178.019037: ipv6_gro_complete: (ipv6_gro_complete+0x0/0xe0) skb=0xffff95b6e89cc800 len=176

# On this upper interface which is an IPv6 Tunnel on top of the “XXXvlan” / “eth0”, the skb still has the small “gso_size”:
<idle>-0 [007] ..s. 171178.019059: napi_gro_receive_entry: dev=Tunnel1 napi_id=0x0 queue_mapping=0 skbaddr=ffff95b6e89cc800 vlan_tagged=0 vlan_proto=0x0000 vlan_tci=0x0000 protocol=0x0800 ip_summed=3 hash=0xfa7500d4 l4_hash=1 len=128 data_len=24 truesize=3968 mac_header_valid=1 mac_header=-62 nr_frags=1 gso_size=24 gso_type=0x1

# The merged packet is then forwarded to the external interface “eth2” with the same small “gso_size”:
<idle>-0 [007] ..s. 171178.019066: net_dev_start_xmit: dev=eth2 queue_mapping=7 skbaddr=ffff95b6e89cc800 vlan_tagged=0 vlan_proto=0x0000 vlan_tci=0x0000 protocol=0x0800 ip_summed=3 len=142 data_len=24 network_offset=14 transport_offset_valid=1 transport_offset=34 tx_flags=0 gso_size=24 gso_segs=2 gso_type=0x1

Two main questions:
- The last log entry indicates that the whole packet’s length 142 is very small with a paged data length of 24, but it is “required” for segmentation (gso_type=0x1) with “gso_size=24” (the same as the paged data amount) which looks strange because there is no segmentation required for this egress packet at all.

- Checking description of GSO and GRO at "kernel.org/doc/Documentation/networking/segmentation-offloads.txt", I understand that when GSO is applied each skbuff is resized to match the MSS provided via skb_shinfo()->gso_size.

"What occurs in GSO is that a given skbuff will have its data broken out over multiple skbuffs that have been resized to match the MSS provided via skb_shinfo()->gso_size."

In our TCP flow, the TCP MSS is always set higher than 1024 byte, so it's a bit unexpected that we have segmentation with gso_size=24!

Thanks in advance!!!

You are entitled to commercial support for your enterprise server.
Login into your account and create a support ticket.
https://www.suse.com/home/