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: <8af4dce7-f2a0-286a-bb5b-36c66d05c0f3@huawei.com>
Date:   Thu, 9 Jul 2020 10:16:14 +0800
From:   tanhuazhong <tanhuazhong@...wei.com>
To:     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 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?

Thanks for reviewing:)

>>
>> Signed-off-by: Huazhong Tan <tanhuazhong@...wei.com>
>> ---
>>   include/linux/netdev_features.h | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
>> index 2cc3cf8..c7eef16 100644
>> --- a/include/linux/netdev_features.h
>> +++ b/include/linux/netdev_features.h
>> @@ -207,7 +207,7 @@ static inline int find_next_netdev_feature(u64 feature, unsigned long start)
>>   				 NETIF_F_FSO)
>>   
>>   /* List of features with software fallbacks. */
>> -#define NETIF_F_GSO_SOFTWARE	(NETIF_F_ALL_TSO | \
>> +#define NETIF_F_GSO_SOFTWARE	(NETIF_F_ALL_TSO | NETIF_F_GSO_UDP_L4 | \
>>   				 NETIF_F_GSO_SCTP)
>>   
>>   /*
>>
> 
>