Message-ID: <CAKgT0UezzJc7FDs=VFrxKCi5=YxEXvWrXt6jqA=tefd8uBTF0g@mail.gmail.com>
Date:   Thu, 16 Nov 2017 10:20:03 -0800
From:   Alexander Duyck <alexander.duyck@...il.com>
To:     Or Gerlitz <gerlitz.or@...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 Thu, Nov 16, 2017 at 9:41 AM, Or Gerlitz <gerlitz.or@...il.com> wrote:
> 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.

I am trying to focus on this area. The problem is you keep assuming
what we can and can't do in our hardware. I am not certain we can
handle the "learning" aspect of things. The biggest issue is that our
hardware was designed to be a VEPA with a filter based hairpin. It
really wasn't designed to be a switch. My concern is you may have been
misinformed about what our hardware can and cannot do. In addition
changing our firmware for the parts supported by i40e isn't that easy.
In addition there is no guarantee that we can do what is being asked
per PCIe function, it might be a global impact on the entire device.
If that were the case then it isn't an option since we can't have one
function breaking another. There are a lot of what-if scenarios that
we have to sort out, if we can even get the firmware update for this
since it was mostly locked down and in maintenance mode.

> 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

This is essentially what I hope to support with source macvlan based
port representors.

> learning: respond to SWITCHDEV_FDB_ADD_TO_DEVICE events

This requires that we see the traffic. We have to figure out if we can
actually make the CPU the default target and can then get the traffic
out of the uplink interface without horribly breaking things. It will
take time to see if we can even do it.

The problem is the CPU/PF is only the default target for traffic
coming from the uplink on our devices. Anything the VF sends will
default to the uplink unless there is a filter for it to route it
otherwise.

> 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

This is much easier said than done when you are working with a device
that was architected years before switchdev was a thing. I'll see what
we can do, but I cannot make any promises.

- Alex

Powered by blists - more mailing lists