Thank you for your reply.
I am reading the source code of this logic but it is really hard to understand
every handling details.
static void xlate_actions__(struct xlate_in *xin, struct xlate_out *xout)
(...skip...)
flow_wildcards_init_catchall(wc);
memset(&wc->masks.in_port, 0xff, sizeof wc->masks.in_port);
memset(&wc->masks.skb_priority, 0xff, sizeof wc->masks.skb_priority);
memset(&wc->masks.dl_type, 0xff, sizeof wc->masks.dl_type);
(...skip...)
>>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.
That makes looking forward to it!
Thanks.
At 2015-09-09 15:18:54, "Justin Pettit" <jpet...@nicira.com> wrote:
>
>> 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
