Subscribe: Comments for Network Heresy
http://networkheresy.wordpress.com/comments/feed/
Preview: Comments for Network Heresy

Comments for Network Heresy



Tales of the network reformation



Last Build Date: Fri, 11 Nov 2016 14:50:44 +0000

 



Comment on OVN, Bringing Native Virtual Networking to OVS by OVS 2.6 and The First Release of OVN – NFVPE Blog

Fri, 11 Nov 2016 14:50:44 +0000

[…] of 2015, the Open vSwitch team announced that they planned to start a new project within OVS called OVN (Open Virtual Network).  The timing could not have been better for me as I was looking around for a new project.  I dove […]



Comment on OVN, Bringing Native Virtual Networking to OVS by OVS 2.6 and The First Release of OVN | Russell Bryant

Thu, 29 Sep 2016 16:00:15 +0000

[…] of 2015, the Open vSwitch team announced that they planned to start a new project within OVS called OVN (Open Virtual Network).  The timing could not have been better for me as I was looking around for a new project.  I dove […]



Comment on Accelerating Open vSwitch to “Ludicrous Speed” by Sanjeev Rampal

Thu, 03 Dec 2015 07:42:43 +0000

What is the net packets per second typically achievable with OVS 2.1 or 2.3 (in an Openstack environment inclusive of the effect of linux iptables and multiple bridges etc on performance). The Paris summit talk mentioned 200K pps seen "in the wild" with Intel Xeon CPUs. What's a typical number these days ?



Comment on Accelerating Open vSwitch to “Ludicrous Speed” by Srinivasa Addepalli

Sat, 06 Jun 2015 17:33:28 +0000

Yes, It is true that megaflow performance would be better than going through set OF tables (some times number of OF tables in the pipeline could be in double digits). I was wondering the efficacy of megaflows when external controllers program highly granular flows. Hence, the suggestion of doing OF table processing within the datapath would be beneficial. You gave two main reasons for not pushing OF packet processing to Kernel. 1. Slowdown resulting from processing all the packets in the kernel without a flow cache. 2. Increase in the complexity of Kernel Data Path and resulting that to slow down on the features. On (1) : I was not suggesting to remove the "flow cache". Flow Cache, i believe, need to be there even if the entire OF pipeline processing is moved to the Kernel. By moving OF table processing in the Kernel for packets that don't match the 'flow cache table", one could reduce the interaction with the "ovs-vswitchd" even in cases where some external controller programs the highly granular flows (Could be 5-tuple granular flows). On (2) : That is a good point. But many in the industry are exploring user space based "Data Path" or iNIC based "Data Path". The type of complexity in those data path implementation is not as big as Kernel data path implementation. Moreover, the type of hardware in iNIC accelerates lookup performance and hence going through OF tables for cache-miss packet is not bad. I am wondering whether you see merits in extending DPIF to allow selective data path implementations to do their own OF table processing. Thanks Srini



Comment on Accelerating Open vSwitch to “Ludicrous Speed” by justindpettit

Sat, 06 Jun 2015 06:47:14 +0000

The megaflows are a cache of what should happen to packets of a certain format. Consulting this cache is much faster than processing the entire OpenFlow table. In addition to the slowdown that would result from processing all the packets in the kernel without a flow cache, the added complexity would likely not be welcomed in the kernel and would slow down feature additions. We wrote an NSDI paper that goes into a lot more detail than this blog post that might be of interest to you: http://openvswitch.org/support/papers/nsdi2015.pdf As for more stateful services, we've been taking the approach of leveraging existing kernel components and using OVS to steer traffic towards those functionality blocks. For example, we used the Linux connection tracker to implement a firewall: http://openvswitch.org/support/ovscon2014/17/1030-conntrack_nat.pdf We're still thinking about how best to add features such as NAT and DPI, but they are in our development plans.



Comment on Accelerating Open vSwitch to “Ludicrous Speed” by Srini

Thu, 04 Jun 2015 16:08:34 +0000

An observation is that "megaflows" feature improves TPS performance if OF flows have wild card values. In some applications - such as distributed firewall, distribution load balancer and even service function scenarios - OVS is configured with large number of exact match flows. In those cases, as we understand, megaflows feature does not help in improving the connection rate performance. It would be good, if OF flow tables themselves are pushed into Kernel DP so that flow-cache miss packets are processed within the kernel. Any comment from others with respect to this observation and proposed solution.



Comment on OVN, Bringing Native Virtual Networking to OVS by justindpettit

Thu, 26 Mar 2015 15:50:42 +0000

There is no requirement for the underlay to support multicast. If you have more technical questions about the architecture, I'd encourage you to post to the ovs-dev mailing list, where all the development is happening.



Comment on OVN, Bringing Native Virtual Networking to OVS by bmullan

Thu, 26 Mar 2015 02:22:31 +0000

Justin... I read thru the link to the architecture and also the rest of that thread. One question I had though was ... will the underlay network have to have multicast enabled to support a vxlan capability or will a unicast vxlan solution be included in OVN?



Comment on OVN, Bringing Native Virtual Networking to OVS by bmullan

Thu, 26 Mar 2015 00:41:30 +0000

Thanks Justin that link helps.



Comment on OVN, Bringing Native Virtual Networking to OVS by justindpettit

Wed, 25 Mar 2015 23:04:27 +0000

OVN will expose a northbound API that can be used by any management system. We are working with members of the OpenStack community on a plugin that will work with OVN, but OVN will not be tied to OpenStack. In fact, we've spoken with other CMS (cloud management system) providers about integrating OVN with their platforms. The link to the architecture describes a bit better how a CMS communicates with OVN.