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. Others (like Florian who has been working to extend DSA or those pushing hardware vendors to make SDKs more open) where the existing bridging/ routing/offload code can take advantage of the hardware offload/encap available in merchant silicon. The general idea seems to add the knowledge of offload hardware to the kernel -- either via new ndo_ops or netlink. This gives users who have this hardware the ability to have a solution for their router/switch that makes it feel like Linux is actually helping make forwarding decisions -- rather than just being the kernel chosen to provide an environment where some other non-community code runs that makes all of the decisions. 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. Of course that may be way too optimistic for this crowd! :-D _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
