[ovs-dev] Important changes to OVS datapath interactions

Justin Pettit jpettit at nicira.com
Sat Nov 3 16:28:55 UTC 2012


Thrusday night, I pushed a series of patches to the master branch that change the way datapaths are handled by OVS.  This is part of the work we're doing to rework tunnel handling and will allow bridges to share tunnels, as is needed for multicast VXLAN support.  Additionally, this work will allow us in the future to make patch ports much more efficient.

The most visible change is that all bridges will share a single backing datapath.  For example, if you create bridges br0 (with ports eth0 and eth1 attached) and br1, and then run "ovs-dpctl show", you will only see a single datapath:

-=-=-=-=-=-=-=-=-=-
root at vm-vswitch:~# ovs-dpctl show
system at ovs-system:
	lookups: hit:100040 missed:7899 lost:0
	flows: 4
	port 0: ovs-system (internal)
	port 1: br0 (internal)
	port 2: br1 (internal)
	port 3: eth0
	port 4: eth1
-=-=-=-=-=-=-=-=-=-

There are a few things of note here:

	- The kernel datapath is called "ovs-system" regardless of what the bridges are called.
	- Port 0 is no longer taken by a bridge's local port, but is now used by "ovs-system".
	- The bridges' local ports now have non-zero port numbers and don't have separate datapath instances.
	- The attached devices appear together with bridges to which they are not attached.

As a result of this, we had to break the association between datapath port numbers and OpenFlow port numbers.  Previously, datapath port number 0 mapped to OpenFlow port number 65534, and all the other port numbers were the same.  With this change that doesn't work.  The most obvious example is that the bridges' local ports can't all have datapath port 0, and they all need to have OpenFlow port 65534 (as defined by the standard).

If you have tests that depend on the prior mapping, they will likely break.  One of the changes included in this series is that you can request the OpenFlow port number through the "ofport_request" Interface column, which may make things easier.  Keep in mind that the port number request must be made in the same transaction as the creation.

This change also means that datapath flow entries are shared among bridges.  When you run "ovs-dpctl dump-flows", you'll see all flows for all bridges. (As part of this series, the dump-flows and del-flows commands no longer require an argument, since they generally will always refer to the single datapath.)

-=-=-=-=-=-=-=-=-=-
root at vm-vswitch:~# ovs-dpctl dump-flows
in_port(3),eth(src=50:54:00:00:00:01,dst=50:54:00:00:00:03),eth_type(0x0800),ipv4(src=192.168.0.1,dst=192.168.0.2,proto=1,tos=0,ttl=64,frag=no),icmp(type=8,code=0), packets:2967, bytes:290766, used:0.308s, actions:4
in_port(4),eth(src=50:54:00:00:00:03,dst=50:54:00:00:00:01),eth_type(0x0800),ipv4(src=192.168.0.2,dst=192.168.0.1,proto=1,tos=0,ttl=64,frag=no),icmp(type=0,code=0), packets:2967, bytes:290766, used:0.269s, actions:3
-=-=-=-=-=-=-=-=-=-

As you can imagine, if you only wanted to see the flows for br1, this would be confusing.

These changes clearly make debugging with ovs-dpctl more difficult, so the patch series adds a number of "ovs-appctl dpif/*" commands that provide the information you used to get from ovs-dpctl.  The commands that were added are:

	ovs-appctl dpif/list-dps
	ovs-appctl dpif/show [br…]
	ovs-appctl dpif/dump-flows <br>
	ovs-appctl dpif/del-flows <br>

Now, when you run "ovs-appctl dpif/show", you'll see information about individual bridges:

-=-=-=-=-=-=-=-=-=-
root at vm-vswitch:~# ovs-appctl dpif/show
br0 (system at ovs-system):
	lookups: hit:100053 missed:7899 lost:0
	flows: 2
	br0 65534/1: (internal)
	eth0 2/3:
	eth1 1/4:
br1 (system at ovs-system):
	lookups: hit:100053 missed:7899 lost:0
	flows: 0
	br1 65534/2: (internal)
-=-=-=-=-=-=-=-=-=-

A couple things to notice:

	- The output related to ports is a bit different.  The format now contains two numbers separated by a slash.  The number on the left is the OpenFlow port number, and the number on the right is the datapath port number.  For example, br0 has an OpenFlow port number of 65534 and the datapath port number is 1.
	- The counters for "lookups" is the same for both bridges.  I need to clean that up, but right now it just returns lookup stats from the backing datapath.

With the new ovs-appctl command, when you dump flows, you'll just see the ones relevant to the bridge you requested:

-=-=-=-=-=-=-=-=-=-
root at vm-vswitch:~# ovs-appctl dpif/dump-flows br0
in_port(4),eth(src=50:54:00:00:00:03,dst=50:54:00:00:00:01),eth_type(0x0800),ipv4(src=192.168.0.2,dst=192.168.0.1,proto=1,tos=0,ttl=64,frag=no),icmp(type=0,code=0), packets:1261, bytes:123578, used:1.227s, actions:3
in_port(3),eth(src=50:54:00:00:00:01,dst=50:54:00:00:00:03),eth_type(0x0800),ipv4(src=192.168.0.1,dst=192.168.0.2,proto=1,tos=0,ttl=64,frag=no),icmp(type=8,code=0), packets:4437, bytes:434826, used:1.263s, actions:4
root at vm-vswitch:~# 
root at vm-vswitch:~# ovs-appctl dpif/dump-flows br1
root at vm-vswitch:~#
-=-=-=-=-=-=-=-=-=-

The "ovs-appctl del-flows <br>" command works as expected, and will just delete the flows for "<br>".

Another benefit is that the new "ovs-appctl dpif/*" commands work with any datapath (e.g., the userspace one) and not just the kernel one.

As you can imagine, this is a fairly substantial change, so master may be a bit unstable for a couple of days.  I'll be working with our QA to get a regression run ASAP and fix any issues that come from that.

--Justin





More information about the dev mailing list