netdev - Re: SRIOV switchdev mode BoF minutes

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: <CAJ3xEMi_Dz57H8ekuxFKzCSE9OnYmHULUndOwAKaM_42Nh_Qhw@mail.gmail.com>
Date:   Thu, 16 Nov 2017 19:41:22 +0200
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Alexander Duyck <alexander.duyck@...il.com>
Cc:     David Miller <davem@...emloft.net>,
        Anjali Singhai Jain <anjali.singhai@...el.com>,
        Andy Gospodarek <gospo@...adcom.com>,
        Michael Chan <michael.chan@...adcom.com>,
        Simon Horman <simon.horman@...ronome.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        John Fastabend <john.fastabend@...il.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Jiri Pirko <jiri@...lanox.com>,
        Rony Efraim <ronye@...lanox.com>,
        Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: SRIOV switchdev mode BoF minutes

On Wed, Nov 15, 2017 at 1:05 AM, Alexander Duyck
<alexander.duyck@...il.com> wrote:
> On Tue, Nov 14, 2017 at 1:50 PM, Or Gerlitz <gerlitz.or@...il.com> wrote:

>> all dealing with the sriov e-switch as a HW switch which should
>> be programmed
>> by the host stack according to well known industry models that apply
>> on physical switches, e.g
>>
>> 1. L2 FDB (Linux Bridge)
>> 2. L3 FIB (Linux Routers)
>> 3. ACLS (Linux TC)
>>
>> [3] is what implemented by the upstream sriov switchdev drivers, [1] and [2] we
>> discussed on netdev, maybe you want to play with [1] for i40e? I had a slide on
>> that in the BoF

> So for i40e we will probably explore option 1, and possibly option 3
> though as I said we still have to figure out what we can get the
> firmware to actually do for us. That ends up being the ultimate
> limitation.

I think Intel/Linux/sriov wise, it would be good if you put now the
focus on that small
corner of the universe and show support for the new community lead
mode by having
one of your current drivers support that.

FDB support would be great and it will help transition existing legacy
mode users to the switchdev
mode, b/c essentially FDBs is what each driver now configures their HW
from within, where's if
we manage to get a bridge to be offloaded, all what left is systemd
script that creates the VF,
puts the driver into switchdev mode, creates a bridge with the reps,
and that is it!!

I have presented a slide in our BoF re what does it take to support
FDB, here it is:

1. create linux bridge (e.g.1q), assign VF and uplink rep netdevices
to the bridge
2. support the switchdev FDB notifications in the HW driver

learning: respond to SWITCHDEV_FDB_ADD_TO_DEVICE events

aging: respond to SWITCHDEV_FDB_DEL_TO_DEVICE events (del FDB from HW)
enhance the driver/bridge API to allows drivers provide last-use
indications on FDB entries

STP:

fwd      - offload FDBs as explained above
learning - make sure HW flow miss (slow path) goes to CPU
discard  - add drop HW rule

flooding:

use SW based flooding