[ovs-dev] Megaflows Question

[openvswitcher]

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.


I mean the treatment for the packet 'nw_dst=9.8.8.8' should be 'action output:200' after I added the flow in openvswitch userspace,
but the packet will be treated by the flow-cache originally used for 'nw_dst=8.8.8.8', so I think the the 'action output:200' will never be applied
to 'nw_dst=9.8.8.8' unless the flow-cache in kernel get timeout.


The treatment is not right for 'nw_dst=9.8.8.8', is it?




At 2015-09-10 01:26:36, "Jarno Rajahalme" <jrajahalme at nicira.com> wrote:


On Sep 8, 2015, at 11:34 PM, openvswitcher <openvswitcher at 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