While experimenting with Vxlan tunnels, I've reached a topology where the
Vxlan interface's MTU was 1500 while base-interface was smaller [600].
While 'regular' packets broke via ip-fragmentation, GSO SKBs passing from
the vxlan interface to the base interface remained whole, and their
`gso_size' remained matching to that of the vxlan-interface's MTU;
This caused the HW to drop said packets, as it would have resulted with
the device sending to the line packets with length larger than the mtu.
Is this broken on the udp-tunnel transmit path, the setup or the driver [qede]?
On 2016/6/7 14:05, Yuval Mintz wrote:
While experimenting with Vxlan tunnels, I've reached a topology where the
Vxlan interface's MTU was 1500 while base-interface was smaller [600].
While 'regular' packets broke via ip-fragmentation, GSO SKBs passing from
the vxlan interface to the base interface remained whole, and their
`gso_size' remained matching to that of the vxlan-interface's MTU;
This caused the HW to drop said packets, as it would have resulted with
the device sending to the line packets with length larger than the mtu.
Is this broken on the udp-tunnel transmit path, the setup or the driver [qede]?
I believe it's identical to issue I met before[1], the owner of the
offending code
believe a host can't generate packet size larger than the underlying NIC
MTU and
refuse to do the GSO here.
[1]: https://patchwork.ozlabs.org/patch/415791/