On Wed, Nov 15, 2017 at 1:05 AM, Alexander Duyck <alexander.du...@gmail.com> wrote: > On Tue, Nov 14, 2017 at 1:50 PM, Or Gerlitz <gerlitz...@gmail.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
