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@vm-vswitch:~# ovs-dpctl show
system@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@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@vm-vswitch:~# ovs-appctl dpif/show
br0 (system@ovs-system):
lookups: hit:100053 missed:7899 lost:0
flows: 2
br0 65534/1: (internal)
eth0 2/3:
eth1 1/4:
br1 (system@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@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@vm-vswitch:~#
root@vm-vswitch:~# ovs-appctl dpif/dump-flows br1
root@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
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
