netdev - Re: [RFC net-next 1/2] udp: add NETIF_F_GSO_UDP_L4 to NETIF_F_SOFTWARE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a71eaf51-eb05-f812-e1f9-f92ce55f5379@gmail.com>
Date:   Wed, 8 Jul 2020 19:28:35 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     tanhuazhong <tanhuazhong@...wei.com>,
        Eric Dumazet <eric.dumazet@...il.com>, davem@...emloft.net,
        willemb@...gle.com
Cc:     netdev@...r.kernel.org, linuxarm@...wei.com, kuba@...nel.org
Subject: Re: [RFC net-next 1/2] udp: add NETIF_F_GSO_UDP_L4 to
 NETIF_F_SOFTWARE_GSO



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.