netdev - Re: [net-next 1/4] i40e/i40evf: Add capability exchange for outer checksum

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 7 Apr 2017 06:27:42 -0700
From:   Alexander Duyck <alexander.duyck@...il.com>
To:     Or Gerlitz <gerlitz.or@...il.com>
Cc:     Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        David Miller <davem@...emloft.net>,
        Preethi Banala <preethi.banala@...el.com>,
        Linux Netdev List <netdev@...r.kernel.org>,
        "nhorman@...hat.com" <nhorman@...hat.com>,
        "sassmann@...hat.com" <sassmann@...hat.com>,
        "jogreene@...hat.com" <jogreene@...hat.com>,
        Alan Brady <alan.brady@...el.com>,
        Jesse Brandeburg <jesse.brandeburg@...el.com>,
        Jacob Keller <jacob.e.keller@...el.com>
Subject: Re: [net-next 1/4] i40e/i40evf: Add capability exchange for outer checksum

On Thu, Apr 6, 2017 at 11:38 PM, Or Gerlitz <gerlitz.or@...il.com> wrote:
> On Fri, Apr 7, 2017 at 6:23 AM, Jeff Kirsher
> <jeffrey.t.kirsher@...el.com> wrote:
>> From: Preethi Banala <preethi.banala@...el.com>
>>
>> This patch adds a capability negotiation between VF and PF using ENCAP/
>> ENCAP_CSUM offload flags in order for the VF to support outer checksum
>> and TSO offloads for encapsulated packets.
>
> [...]
> -#define I40E_VIRTCHNL_VF_OFFLOAD_    0X00100000
> +#define I40E_VIRTCHNL_VF_OFFLOAD_ENCAP         0X00100000
> +#define I40E_VIRTCHNL_VF_OFFLOAD_ENCAP_CSUM    0X00200000
>
> what happens when one of the PF or VF doesn't have this hunk, e.g one
> assumes value X and one assumes value Y for ENCAP_CSUM

The way the capability exchange works is that the VF advertises what
it wants and the PF does an AND of that value and a bitmask of what
the PF supports. The VF then receives the result and has to work with
that. So a legacy PF driver will cause the VF to drop support for
something like this because these bits are not supported.

That way both the PF and VF should know what to expect from each other
in terms of what is supported without it being implied based on the VF
device IDs.

- Alex