> On Sep 8, 2015, at 11:34 PM, openvswitcher <openvswitc...@163.com> wrote: > > Thank you very much. > > >The OpenFlow flows in question are 10.0.0.0/24, which matches: > > 00001010.00000000.00000000.xxxxxxxx > >and 10.0.0.1/32, which matches: > > 00001010.00000000.00000000.00000001 > >The packet matched against them contains 8.8.8.8, which has the value: > > 00001000.00001000.00001000.00001000 > >The megaflow match 0.0.0.0/2.0.0.0 checks for: > > xxxxxx0x.xxxxxxxx.xxxxxxxx.xxxxxxxx > As you descripted, the table rules in openflow switch as shown: > table 1: > match inport + dst MAC > table 2: > priority 100 match 10.0.0.0/24 go to controller > priority 100 match 10.0.0.1 go to next table (table 3) > table 3: > priority 1 goto egress table > > So the megaflow installed in linux kernel is used to match the rule: > " priority 1 goto egress table ". > > But I don't know why the 'xxxxxx0x.xxxxxxxx.xxxxxxxx.xxxxxxxx' is calculated > as the result. > Why is it not "xxxxxxxx.xxxx0xxx.xxxxxxxx.xxxxxxxx" which can also be used to > differ the > 00001010.00000000.(=10.0) from 00001000.00001000(=8.8) ? >
The algorithm chooses one of the differing bits. Which bit is selected is unto the implementation and subject to change in the future, if there is any benefit for such a change. > And another problem is: > in the situation '0.0.0.0/2.0.0.0' is used, if I add another flow > 'nw_dst=9(bit=00001001).8.8.8 action output:200' > then the actions will be not same with 'nw_dst=8.8.8.8' but the flow > installed in kernel will make the packet > of which the ip destination is 9.8.8.8 not be upcalled to userspace by > flow-miss, it will use the flow for '8.8.8.8' > in kernel. Is this right? > Yes, this is what megaflows are for to begin with. The new packet matches the same megaflow as the first one, and by the way the megaflows are constructed, this treatment is correct also for the second packet. Jarno _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
