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]
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)
>>   
>>   /*
>>
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ