On 7/8/20 7:16 PM, tanhuazhong wrote:
>
>
> On 2020/7/8 13:26, Eric Dumazet wrote:
>>
>>
>> On 7/7/20 8:48 PM, Huazhong Tan wrote:
>>> Add NETIF_F_SOFTWARE_GSO to the the list of GSO features with
>>
>>
>> s/NETIF_F_SOFTWARE_GSO/NETIF_F_GSO_UDP_L4/
>>
>
> yes, thanks.
>
>>> a software fallback. This allows UDP GSO to be used even if
>>> the hardware does not support it, and for virtual device such
>>> as VxLAN device, this UDP segmentation will be postponed to
>>> physical device.
>>
>> Is GSO stack or hardware USO able to perform this segmentation,
>> with vxlan (or other) added encapsulation ?
>>
>
> I have tested this patch with vxlan and vlan in i40e, the driver
> of vxlan and vlan uses NETIF_F_SOFTWARE_GSO.
> case 1:
> tx-udp-segmentation of virtual device and i40e is on, then the
> UDP GSO is handled by hardware.
> case 2:
> tx-udp-segmentation of virual device is on, i40e is off, then
> the UDP GSO is handled between xmit of virtual device and physical device.
> case 3:
> tx-udp-segmentation of virtual device and i40e is off, then
> the UDP GSO is handled before calling virtual device's xmit.
>
> the packet captured on receiver is same for the above cases.
> so the behavior of UDP is similar to TCP (which has already been supported)?
>
>> What about code in net/core/tso.c (in net-next tree) ?
>>
>
> by reading the code, i can not find anything related to the
> tunnel header. Is there any way to verify it?
>
TSO is supposed to be native ipv4 + TCP
TSO6 is supposed to be native ipv6 + TCP
Variants with added encapsulation need other GSO bits
(SKB_GSO_GRE, SKB_GSO_IPXIP4, SKB_GSO_IPXIP6 ...)
net/core/tso.c does not yet support the variants. Only native TCP/UDP
I do not see vxlan adding a bit in gso_type, so I am kind-of-confused.
