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.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
