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]
Message-ID: <CAKgT0UdUbz3AoyaHDyMUceS0cY3Li_MMKYJW_U+ZKY1ABYMDrQ@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ