[ovs-dev] Hybrid VLAN capability

[Jean Tourrilhes]

On Fri, Mar 06, 2015 at 10:27:22AM -0800, Ben Pfaff wrote:
> 
> Another possibility is to use the "conjunctive match" feature in
> (upcoming) OVS 2.4.  With this feature, you can effectively construct
> flows that say,
> 
>    (in_port in {set_A}) and (vlan_id in {set_B}),actions=...
> 
> by adding n_A + n_B + 1 flows to the flow table, where n_A is the
> number of elements in {set_A} and n_B is the number in {set_B}.  But I
> doubt that that feature maps well to hardware.

	I believe this will only help for ingress filtering. I think
ingress filtering is easy, you can just do it with two tables :

table 0:
in_port=1,actions=goto_table:1
in_port=2,actions=goto_table:1
in_port=3,actions=goto_table:1
in_port=4,actions=goto_table:1
in_port=7,actions=goto_table:2

table 1:
in_port=*,vlan_id=100,actions=goto_table:2
in_port=*,vlan_id=110,actions=goto_table:2
in_port=*,vlan_id=120,actions=goto_table:2
in_port=*,drop

table 2:
in_port=1,actions=output:2,output:7,output:8
in_port=2,actions=output:1,output:7,output:8
in_port=3,actions=output:4,output:7,output:8
in_port=4,actions=output:3,output:7,output:8
in_port=7,actions=output:8

	It is clear that "conjunctive match" would help to collapse
the first two tables into one, but there may be other way to do that,
such as using bitmasks on the VLAN or just wildcarding input port.
	In term of what would be more efficient in the datapath,
I guess that would depend on the traffic pattern and how forwarding
rules look like. What is clear to me is that having all collapsed into
one megaflow lookup would beat having an additional specialised VLAN
lookup in the port itself.

	Where "conjunctive match" does not help is with egress
filtering. Obviously, actset_output would help, but it's tricky to use
in ingress tables and is non-transparent to the forwarding rules.

	With Egress Tables :

table 0:
in_port=1,actions=goto_table:1
in_port=2,actions=goto_table:1
in_port=3,actions=goto_table:1
in_port=4,actions=goto_table:1
in_port=7,actions=goto_table:2
in_port=8,actions=goto_table:2

table 1:
in_port=*,vlan_id=100,actions=goto_table:2
in_port=*,vlan_id=110,actions=goto_table:2
in_port=*,vlan_id=120,actions=goto_table:2
in_port=*,drop

table 2:
in_port=1,actions=output:2,output:7,output:8
in_port=2,actions=output:1,output:7,output:8
in_port=3,actions=output:4,output:7,output:8
in_port=4,actions=output:3,output:7,output:8
in_port=7,actions=output:8

First egress == 200

table 200:
actset_output=1,actions=goto_table:201
actset_output=2,actions=goto_table:201
actset_output=3,actions=goto_table:201
actset_output=4,actions=goto_table:201
actset_output=7,actions=
actset_output=8,actions=

table 201:
actset_output=*,vlan_id=100,actions=
actset_output=*,vlan_id=110,actions=
actset_output=*,vlan_id=120,actions=
actset_output=*,actions=clear_actions

	How do that look like ? Clean enough ?
	Again, "conjunctive match" would allow you to collapse table
200 and 201. But that's only an optimisation ;-)
	But to me the main issue is avoiding an extra lookup in the
output port. I personally believe that you won't have any trouble
folding egress tables into a single megaflow lookup without needing
recirculation in most cases. Recirculation is probably needed only
when using OFPP_ALL, group of type all or multiple output actions.

	Regards,

	Jean