netdev - Re: [net-next 01/15] i40e: Introduce VF port representor/control netdevs

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]

Message-ID: <57E2BC74.5040905@intel.com>
Date:   Wed, 21 Sep 2016 09:59:32 -0700
From:   "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
To:     Or Gerlitz <gerlitz.or@...il.com>
CC:     Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        David Miller <davem@...emloft.net>,
        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>,
        guru.anbalagane@...cle.com, Ilya Lesokhin <ilyal@...lanox.com>,
        Andy Gospodarek <andy@...yhouse.net>,
        John Fastabend <john.r.fastabend@...el.com>,
        Jiri Pirko <jiri@...lanox.com>,
        Rony Efraim <ronye@...lanox.com>
Subject: Re: [net-next 01/15] i40e: Introduce VF port representor/control
 netdevs



On 9/21/2016 12:04 AM, Or Gerlitz wrote:
> On Wed, Sep 21, 2016 at 8:45 AM, Samudrala, Sridhar
> <sridhar.samudrala@...el.com> wrote:
>> On 9/20/2016 9:22 PM, Or Gerlitz wrote:
>>> On Wed, Sep 21, 2016 at 6:43 AM, Jeff Kirsher
>>> <jeffrey.t.kirsher@...el.com> wrote:
>>>> From: Sridhar Samudrala <sridhar.samudrala@...el.com>
>>>> This patch enables creation of a VF Port representor/Control netdev
>>>> associated with each VF. These netdevs can be used to control and
>>>> configure
>>>> VFs from PFs namespace. They enable exposing VF statistics, configuring
>>>> link state, mtu, fdb/vlan entries etc.
>>> What happens if someone does a xmit on the VF representor, does the
>>> packet show up @ the VF?
>>> and what happens of the VF xmits and there's no HW steering rule that
>>> matches this, does
>>> the frame show up @ the VF rep on the host?
>> TX/RX are not yet supported via VFPR netdevs in this patch series.
>> Will be submitting this support in the next patchset.
> Okay, good.
>
>>> In other words, can these VF reps serve for setting up host SW based
>>> switching which you
>>> can later offload (through TC, bridge, netfilter, etc)?
>> Yes. These offloads will be possible  via VFPRs.
> cool
>
>>> I am posing these questions because in downstream patch you are adding
>>> devlink support
>>> for set/get the e-switch mode and you declare the default mode to be switchdev.
>>> When the switchdev mode was introduced in 4.8 these RX/TX
>>> characteristics were defined
>>> to be an essential (== requirement) part for a driver to support that mode.
>> The current patchset introduces the basic VFPR support starting with
>> exposing VF stats and syncing link state between VFs and VFPRs.
>> We decided to declare the default mode to be switchdev so that the new code
>> paths will get exercised by default during normal testing.
> so what happens after this patchset is applied and before the future
> work is submitted?
> RX/TX slow path through the VFPRs isn't supported and what about fast
> path? in other words
> what happens when someone loads the driver, sets SRIOV (--> the driver
> set itself to switchdev mode
> and VFPRs are created) and then a VF sends a packet? do you still put
> into the HW the legacy DMAC
> based switching rules? I am not following...

The VF driver requests adding the dmac based filter rules via mailbox 
messages to PF and that is
not changed in this patchset.
Once we have VFPR TX/RX support, we will not allow the VF driver to add 
these rules, Instead a host based
program will be able to add these rules to enable the fast path.

Thanks
Sridhar