Hi, Ben,
You're correct. I think the principle is to cache as few bits as possible.
In fact to
differentiate two prefixes, you just need 1 more bits in positions [16,24].
We are currently doing some research to accelerate the performance of OVS.
Since the prefix mask is not contiguous, if there are too many megaflow tuples,
you cannot use tries to prune these tuples, (similar to tuple space search in
ofproto)
and do further acceleration.
Guess current OVS does not need this. Anyway, thank you for your reply.
We would like to contribute to fix other performance issues.
At 2016-03-20 00:31:53, "Ben Pfaff" <b...@ovn.org> wrote:
>It's not a bug.
>
>I think that you should read our research paper from NSDI 2015. It
>explains how OVS megaflows work:
> http://openvswitch.org/support/papers/nsdi2015.pdf
>
>On Sat, Mar 19, 2016 at 05:21:00PM +0800, Peng He wrote:
>> Hi, Ben,
>> I am not sure if this is a bug, but I think it probably is as the bit
>> mask is not discontiguous,
>> it can not reserve enough bits for a megaflow? Or this is intended to
>> cache as less bits as possible? (a feature?)
>>
>>
>>
>>
>>
>>
>> At 2016-03-18 23:38:04, "Ben Pfaff" <b...@ovn.org> wrote:
>> >On Fri, Mar 18, 2016 at 05:02:41PM +0800, Peng He wrote:
>> >> Hi, I send this email once, no people replied. I am trying to refresh
>> >> this email for a reply.
>> >> This discontiguous bit mask issue arises in the following case:
>> >>
>> >>
>> >> I installed two rules,
>> >>
>> >>
>> >> ovs-ofctl add-flow br0
>> >> in_port=1,dl_type=0x0800,nw_src=10.2.10.0/24,nw_proto=6,tcp_dst=0x0050,priority=1,actions=drop
>> >> ovs-ofctl add-flow br0
>> >> in_port=1,dl_type=0x0800,nw_src=10.2.0.0/16,nw_proto=6,tcp_dst=0x1f90,priority=1,actions=drop
>> >>
>> >>
>> >> and test the rules with packet (nw_src = 10.2.2.1 and tcp_dst = 8080). I
>> >> got the nw_src mask (in network byte order) 0x8ffff.
>> >> Even you change it to host byte order the bit mask still has
>> >> discontiguous 1-bits 0xFFFF08 = 1111 1111 1111 1111 0000 1000.
>> >
>> >This looks correct to me. Are you reporting a bug? If so, what is it?
>> >
>> >Here's how to reproduce this setup, under "make sandbox":
>> >
>> > ovs-vsctl add-br br0
>> > ovs-ofctl del-flows br0
>> > ovs-ofctl add-flow br0
>> > in_port=1,dl_type=0x0800,nw_src=10.2.10.0/24,nw_proto=6,tcp_dst=0x0050,priority=1,actions=drop
>> > ovs-ofctl add-flow br0
>> > in_port=1,dl_type=0x0800,nw_src=10.2.0.0/16,nw_proto=6,tcp_dst=0x1f90,priority=1,actions=drop
>> > ovs-appctl ofproto/trace br0 tcp,in_port=1,nw_src=10.2.2.1,tcp_dst=8080
>> >
>> >The output is:
>> >
>> > Bridge: br0
>> > Flow:
>> > tcp,in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,nw_src=10.2.2.1,nw_dst=0.0.0.0,nw_tos=0,nw_ecn=0,nw_ttl=0,tp_src=0,tp_dst=8080,tcp_flags=0
>> >
>> > Rule: table=0 cookie=0
>> > priority=1,tcp,in_port=1,nw_src=10.2.0.0/16,tp_dst=8080
>> > OpenFlow actions=drop
>> >
>> > Final flow:
>> > tcp,in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,nw_src=10.2.2.1,nw_dst=0.0.0.0,nw_tos=0,nw_ecn=0,nw_ttl=0,tp_src=0,tp_dst=8080,tcp_flags=0
>> > Megaflow:
>> > recirc_id=0,tcp,in_port=1,nw_src=10.2.0.0/255.255.8.0,nw_frag=no,tp_dst=8080
>> > Datapath actions: drop
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
