netdev - Re: ethtool features: tx-udp_tnl-csum-segmentation and tx-udp

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] [day] [month] [year] [list]

Message-ID: <9b6f1499-db56-9c87-8407-09e4daa5f15e@nvidia.com>
Date:   Mon, 10 May 2021 18:44:03 +0300
From:   Aya Levin <ayal@...dia.com>
To:     Edward Cree <ecree.xilinx@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Saeed Mahameed" <saeedm@...dia.com>
CC:     Tariq Toukan <tariqt@...dia.com>, Moshe Shemesh <moshe@...dia.com>,
        "Maria Pasechnik" <mariap@...dia.com>
Subject: Re: ethtool features: tx-udp_tnl-csum-segmentation and
 tx-udp_tnl-segmentation

Thanks a lot for your response!

On 4/29/2021 5:49 PM, Edward Cree wrote:
> On 29/04/2021 10:16, Aya Levin wrote:
>> I see a strange behavior when toggling feature flags:
>> (1) tx-udp_tnl-csum-segmentation
>> (2) tx-udp_tnl-segmentation
> ...
>> What is the role of each feature flag?
> IIRC, tx-udp_tnl-segmentation controls whether to do TSO on packets that don't
>   have an outer checksum to offload, whereas tx-udp_tnl-csum-segmentation controls
>   the same for packets that _do_ need outer checksum offload.  The difference
>   being whether gso_type is SKB_GSO_UDP_TUNNEL or SKB_GSO_UDP_TUNNEL_CSUM.
Digging further in the code I see that the driver may allow/block inner 
checksum offload by set/unset NETIF_F_HW_CSUM to hw_enc_features at 
driver's load.
I couldn't find a control - is this expected?
> 
> To a first approximation there's one feature flag for each SKB_GSO_* bit, and if
>   an skb's gso_type requires a feature that's not enabled on the device, the core
>   will segment that skb in software before handing it to the driver.
> 
> Documentation/networking/segmentation-offloads.rst may also be useful to read if
>   you haven't already.
> 
> (And note that the kernel's favourite way for hardware to behave is to instead
>   provide GSO_PARTIAL offload / tx-gso-partial, rather than doing protocol-
>   ossified offloads for specific kinds of tunnels.)
> 
> -ed
>