[ovs-dev] [patch net-next v2 8/9] switchdev: introduce Netlink API

[Or Gerlitz]

On 9/23/2014 7:11 AM, Andy Gospodarek wrote:
> On Mon, Sep 22, 2014 at 07:16:47PM -0700, Tom Herbert wrote:
> [...]
>> Alexei, I believe you said previously said that SW should not dictate
>> HW models. I agree with this, but also believe the converse is true--
>> HW shouldn't dictate SW model. This is really why I'm raising the
>> question of what it means to integrate a switch into the host stack.
> Tom, when I read this I cannot help but remind myself that the
> intentions/hopes/dreams of those on this thread and how different their
> views can be on what it means to add additional 'offload support' to the
> kernel.
>
> There are clearly some that are most interested in how an eSwitch on an
> SR-IOV capable NIC be controlled can provide traditional forwarding help
> as well as offload the various technologies they hope to terminate
> at/inside their endpoint (host/guest/container) -- Thomas's _simple_
> use-case demonstrates this. ;)  This is a logical extention/increase in
> functionality that is offered in many eSwitches that was previously
> hidden from the user with the first generation SR-IOV capable network
> devices on hosts/servers.

Indeed.

The idea is to leverage OVS to manage eSwitch (embedded NIC switch) as 
well (NOT to offload OVS).

We envision a seamless integration of user environment which is based on 
OVS with SRIOV eSwitch and the grounds for that were very well supported 
in Jiri’s V1.

The eSwitch hardware does not need to have multiple tables and ‘enjoys’ 
the flat rule of OVS. The kernel datapath does not need to be aware of 
the existence of HW nor its capabilities, it just pushes the flow also 
to the switchdev which represents the eSwitch.

If the flow can be supported in HW it will be forwarded in HW and if not 
it will be forwarded by the kernel

> [....]
>
> And now we also have the patchset that spawned what I think has been
> more excellent discussion.  Jiri and Scott's patches bring up another,
> more generic model that while not currently backed by hardware provided
> an example/vision for what could be done if such hardware existed and
> how to consider interacting with that driver/hardware (that clearly has
> been met with some resistance, but the discussion has been great).
> There ultimate goals appear to be similar to those that want full
> offload/fordwarding support for a device, but via a different method
> than what some would consider standard.
>
> I am personally hopeful that most who are passionate about this will be
> able to get together next month at LPC (or send someone to represent
> them!) so that those interested can sit in the same room and try to
> better understand each others desires and start to form some concrete
> direction towards a solution that seems to meet the needs of most while
> not being an architectural disaster.
>

Yep. LPC is the time and place to go over the multiple use-cases 
(phyiscal switch, eSwitch, eBPF, etc) that could (should) be supported 
by the basic framework.

Or.