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

Date:   Wed, 31 Aug 2016 09:13:39 -0700
From:   Alexander Duyck <alexander.duyck@...il.com>
To:     Yuval Mintz <Yuval.Mintz@...gic.com>
Cc:     netdev <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH 3/5] bnx2x: Add support for segmentation of tunnels
 with outer checksums

On Wed, Aug 31, 2016 at 4:31 AM, Yuval Mintz <Yuval.Mintz@...gic.com> wrote:
> 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.

When you say validation do you mean generating an outer checksum?  If
I recall ndo_features_check applies to Tx features not Rx features.
I'll assume you mean Tx checksum offload and not validation.

> 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.

Right.  That sounds correct so far.

> 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?

I think you may have that correct.  Basically any feature you
advertise as partially supporting via GSO_PARTIAL ends up being tied
to the partial offload after that.  Although from what I have seen the
difference isn't really all that great between GSO_PARTIAL versus TSO.
In many cases the stack generates MSS aligned frames anyway so all
GSO_PARTIAL is really doing is unsharing the header and updating the
header fields.