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

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

Date:   Tue, 20 Sep 2016 22:45:24 -0700
From:   "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
To:     Or Gerlitz <gerlitz.or@...il.com>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>
CC:     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/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.
>
> 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.
>
> 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.

>
> Or
>
>>      # echo 2 > /sys/class/net/enp5s0f0/device/sriov_numvfs
>>      # ip l show
>>      297: enp5s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop portid 6805ca2e7268 state DOWN mode DEFAULT group default qlen 1000
>>      link/ether 68:05:ca:2e:72:68 brd ff:ff:ff:ff:ff:ff
>>      vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off
>>      vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off
>>      299: enp5s0f0-vf0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
>>      link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
>>      300: enp5s0f0-vf1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
>>      link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff