On Mon, Dec 12, 2016 at 11:29:49AM -0500, Eric Garver wrote: > Flow key handling changes: > - Add VLAN header array in struct flow, to record multiple 802.1q VLAN > headers. > - Add dpif multi-VLAN capability probing. If datapath supports > multi-VLAN, increase the maximum depth of nested OVS_KEY_ATTR_ENCAP. > > Refactor VLAN handling in dpif-xlate: > - Introduce 'xvlan' to track VLAN stack during flow processing. > - Input and output VLAN translation according to the xbundle type. > > Push VLAN action support: > - Allow ethertype 0x88a8 in VLAN headers and push_vlan action. > - Support push_vlan on dot1q packets. > > Add new port VLAN mode "dot1q-tunnel": > - Example: > ovs-vsctl set Port p1 vlan_mode=dot1q-tunnel tag=100 > Pushes another VLAN 100 header on packets (tagged and untagged) on > ingress, and pops it on egress. > - Customer VLAN check: > ovs-vsctl set Port p1 vlan_mode=dot1q-tunnel tag=100 cvlans=10,20 > Only customer VLAN of 10 and 20 are allowed. > > Use other_config:vlan-limit in table Open_vSwitch to limit maximum VLANs > that can be matched. This allows us to preserve backwards compatibility. > > Add test cases for VLAN depth limit, Multi-VLAN actions and QinQ VLAN > handling > > Co-authored-by: Thomas F Herbert <[email protected]> > Co-authored-by: Xiao Liang <[email protected]> > Co-authored-by: Eric Garver <[email protected]> > Signed-off-by: Eric Garver <[email protected]>
I'm pretty happy with this. I have only a few comments. This should add some items to NEWS. I'd prefer to see the dot1q-tunnel/cvlan changes split into a second patch. They are logically separate from pure OpenFlow support for QinQ, and require additional thought. I'll look forward to the first non-RFC version. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
