netdev - RE: [RFC PATCH 3/5] bnx2x: Add support for segmentation of tunnels with outer checksums

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:   Wed, 31 Aug 2016 11:31:13 +0000
From:   Yuval Mintz <Yuval.Mintz@...gic.com>
To:     Alexander Duyck <alexander.duyck@...il.com>
CC:     netdev <netdev@...r.kernel.org>
Subject: RE: [RFC PATCH 3/5] bnx2x: Add support for segmentation of tunnels
 with outer checksums

One question I have regarding the feature, regarding the
partial offload compatible with ndo_features_check().

Consider the following example -
Let's assume my adapter is capable of doing outer-csum validation
for vxlan packets, but only if inner network protocol is IPv4,
while at the same time it's capable of doing gso offloading for any
vxlan-encapsulated packet.

In that case, I'll publish NETIF_F_GSO_UDP_TUNNEL_CSUM as
part of my offload capability [& encap capabilities], and in my driver's
implementation of ndo_features_check() I'd remove the feature in case
I'd find out SKB is vxlan whose inner network protocol is ipv6.

Is there a way I could have benefited from the partial offload in that
case? If I understand the feature correctly, if I were to publish
UDP_TUNNEL_CSUM  under partial-gso, it would mean that stack would
peel the feature off until it would decide there's actual need for SW GSO,
thereby denying me the ability of utilizing the HW offload capability for CSUM.

Am I reading it wrong? Or does this trade-off exist?