netdev - Re: [net-next PATCH 5/6] i40e: Add TX and RX support in switchdev mode.

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]

Date:   Thu, 5 Jan 2017 13:50:27 +0200
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
Cc:     Alexander Duyck <alexander.h.duyck@...el.com>,
        John Fastabend <john.r.fastabend@...el.com>,
        Anjali Singhai Jain <anjali.singhai@...el.com>,
        jakub.kicinski@...ronome.com, intel-wired-lan@...ts.osuosl.org,
        Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [net-next PATCH 5/6] i40e: Add TX and RX support in switchdev mode.

On Thu, Jan 5, 2017 at 12:46 AM, Samudrala, Sridhar
<sridhar.samudrala@...el.com> wrote:
>
>
> On 1/3/2017 3:03 PM, Or Gerlitz wrote:
>>
>> On Fri, Dec 30, 2016 at 7:04 PM, Samudrala, Sridhar
>> <sridhar.samudrala@...el.com> wrote:
>>>
>>> On 12/30/2016 7:31 AM, Or Gerlitz wrote:
>>>>
>>>> Are you exposing switchdev ops for the representators? didn't see that
>>>> or maybe it's in the 4th patch which didn't make it to the list?
>>>
>>> Not at this time. In the future patches when we offload fdb/vlan
>>> functionality, we could use switchdev ops.
>>
>> but wait, this is the switchdev mode... even before doing any
>> offloading, you want (need) your representor netdevices to have the
>> same HW ID marking they are all ports of the same ASIC, this you can
>> do with the switchdev parent ID attribute.
>
> OK. I will add switchdev_port_attr_get() with PORT_PARENT_ID support in v3.

Good, I made this comment, b/c we want to create a well defined user-experience
to be taken into account also by upper virtualization layers.

Another piece there to add is have your VF reps implement the
get_phys_port_name ndo,
where as we explain in commit cb67b832921cfa20ad79bafdc51f1745339d0557 is used
as follows:

    Port phys name (ndo_get_phys_port_name) is implemented to allow exporting
    to user-space the VF vport number and along with the switchdev port parent
    id (phys_switch_id) enable a udev base consistent naming scheme:

    SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}=="<phys_switch_id>", \
            ATTR{phys_port_name}!="", NAME="$PF_NIC$attr{phys_port_name}"

    where phys_switch_id is exposed by the PF (and VF reps) and $PF_NIC is
    the name of the PF netdevice.

Or.