> On Sep 8, 2015, at 11:54 PM, openvswitcher <openvswitc...@163.com> wrote: > > Thank you very much. > I found If I enable it, the flows with flow-mask will be installed in kernel. > Otherwise, the flow with no flow-mask wil be installed. > But I could not understand how to calculate the mask should be used. > If only one NORMAL rule exists, and I enabled megaflow, when one virtual > machine ping another one, > the flows bellow are installed. > > root@comm:~# ovs-dpctl dump-flows > skb_priority(0),in_port(9),eth(src=fa:16:3e:49:a8:9b,dst=fa:16:3e:99:79:7f),eth_type(0x0800),ipv4(src=192.168.10.2/0.0.0.0,dst=192.168.10.4/0.0.0.0,proto=1/0,tos=0/0,ttl=64/0,frag=no/0xff), > packets:426, bytes:41748, used:0.692s, actions:11 > skb_priority(0),in_port(11),eth(src=fa:16:3e:99:79:7f,dst=fa:16:3e:49:a8:9b),eth_type(0x0800),ipv4(src=192.168.10.4/0.0.0.0,dst=192.168.10.2/0.0.0.0,proto=1/0,tos=0/0,ttl=64/0,frag=no/0xff), > packets:426, bytes:41748, used:0.692s, actions:9 > > So why the frag flag and the in_port/src mac/dst mac are not masked?
The ingress port and MAC addresses need to be not wildcarded, because the "normal" action does L2 learning and forwarding. The ingress port and source MAC make up the learning portion, and the destination MAC is used for the forwarding decision--they're all relevant fields. I think the ethertype is not wildcarded because it's needed in (the hidden) in-band control rules. I don't remember while the frag field is not wildcarded, but I think it had to do with the kernel interface. We should really document the logic. I'll try to remember to add some documentation around that. --Justin _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
