gt; Date: Monday, May 19, 2014 10:54 PM
>> To: Ryan Wilson
>> Cc: "dev@openvswitch.org" , Ryan Wilson <
>> wr...@nicira.com>
>> Subject: Re: [ovs-dev] [PATCH] ofproto: Remove per-flow miss hash table
>> from upcall handler.
>>
>>
>>
>>
1.1.110,proto=6,tos=0,ttl=64,frag=no),tcp(src=44055,dst=60288),tcp_flags(0x010)
>
> Ryan
>
> From: Alex Wang
> Date: Monday, May 19, 2014 10:54 PM
> To: Ryan Wilson
> Cc: "dev@openvswitch.org" , Ryan Wilson <
> wr...@nicira.com>
> Subject: Re: [ovs-dev
x Wang , "dev@openvswitch.org" <
> dev@openvswitch.org>, Ryan Wilson
>
> Subject: Re: [ovs-dev] [PATCH] ofproto: Remove per-flow miss hash table
> from upcall handler.
>
>On 20 May 2014 17:25, Ryan Wilson wrote:
>
>> Ok turns out my Openflow rules weren't tota
uesday, May 20, 2014 7:06 PM
To: Ryan Wilson mailto:wr...@vmware.com>>
Cc: Alex Wang mailto:al...@nicira.com>>,
"dev@openvswitch.org<mailto:dev@openvswitch.org>"
mailto:dev@openvswitch.org>>, Ryan Wilson
mailto:wr...@nicira.com>>
Subject: Re: [ovs-dev] [P
On 20 May 2014 17:25, Ryan Wilson wrote:
> Ok turns out my Openflow rules weren't totally correct (they were flooding
> all ports like a hub instead of forwarding properly). After adjusting them,
> I achieved equivalent performance with and without my upcall patch (both
> achieved 161-162 trans/s
: Ryan Wilson mailto:wr...@vmware.com>>
Cc: "dev@openvswitch.org<mailto:dev@openvswitch.org>"
mailto:dev@openvswitch.org>>, Ryan Wilson
mailto:wr...@nicira.com>>
Subject: Re: [ovs-dev] [PATCH] ofproto: Remove per-flow miss hash table from
upcall handler.
On Mo
On Mon, May 19, 2014 at 10:25 PM, Ryan Wilson wrote:
> Ok turns out my Openflow rules weren't totally correct (they were flooding
> all ports like a hub instead of forwarding properly). After adjusting them,
> I achieved equivalent performance with and without my upcall patch (both
> achieved 161
Ok turns out my Openflow rules weren't totally correct (they were flooding all
ports like a hub instead of forwarding properly). After adjusting them, I
achieved equivalent performance with and without my upcall patch (both achieved
161-162 trans/second). I'll submit my other version of the patc
Ok, after long last, I was able to get my perf environment to work. Here are
the results for the TCP_CRR (300 flows on server209/210 to be exact) test with
master with and without the flow hash table in up call.
The mean and median transmissions/second are 2-3 lower without the hash table;
I ra
Thanks Ryan, this is a great refactoring.
Looks good to me,
Minor issues:
1. Could you rebase the patch against master? Need to fix some new calls,
added after you posted the patch.
On Wed, May 7, 2014 at 3:14 PM, Ryan Wilson wrote:
> The upcall hander keeps a hash table which hashes flow
I agree completely. I think since this optimization was introduced,
enough as changed that I suspect we can remove it without a negative
impact. Furthermore, we're so sensitive to memory access patterns
now, that I further suspect that removing it may actually help the
average case. That said, w
On Fri, May 09, 2014 at 02:38:33PM -0700, Ryan Wilson wrote:
> Sorry for the delayed response.
No problem.
> Unfortunately, I've had some issues with setting up an NVP perf
> environment lately so I haven't gotten any numbers. When I do, I'll
> publish them on this thread.
>
> Ethan's rationale
Hey Ben,
Sorry for the delayed response. Unfortunately, I've had some issues with
setting up an NVP perf environment lately so I haven't gotten any numbers. When
I do, I'll publish them on this thread.
Ethan's rationale is that it simplifies the code and we don't incur the memory
overhead of a
On Wed, May 07, 2014 at 03:14:01PM -0700, Ryan Wilson wrote:
> The upcall hander keeps a hash table which hashes flow to a list of
> corresponding packets. This used to be necessary as packets with the same flow
> had similar actions and calculating actions used to be a performance
> bottleneck.
>
The upcall hander keeps a hash table which hashes flow to a list of
corresponding packets. This used to be necessary as packets with the same flow
had similar actions and calculating actions used to be a performance bottleneck.
Now that userspace action calculation performance has improved, there i
15 matches
Mail list logo
