On Fri, Mar 7, 2014 at 2:45 PM, Ethan Jackson <et...@nicira.com> wrote:
> I'm surprised its only 10%, do you have a sense of why? Perhaps when > running TCP_CRR we delete the flow the first time we see it, and we > need to do xlate_actions() to generate the list of things to push > stats to anyways? If this is what's going on, do you think if the > miss handlers installed the ukeys this benefit would be larger? > Hmm, it's a tough one. Just because we can spend less time revalidating, doesn't necessarily mean that we are able to handle flows at a faster rate. I suspect that the main difference is when we are operating at the flow limit, which is when handlers stop installing flows and just execute them. Deleting flows as soon as we see them (which is what this patchset does in a test like TCP_CRR) means that we are unlikely to spend any time at/above the flow limit. In most cases, the entire CRR session has completed before we dump the flow. As you say, revalidator threads perform xlate_actions() once for this case anyway, so there is not a lot of benefit from caching its results in this test. If we have miss handlers install the ukeys, this further reduces the amount of work for revalidators to perform, at a fairly minor cost to handlers (as they perform most of the required work already). While I think this allows revalidators to handle even more flows, I'm not sure we'll see much further improvement in TCP_CRR from that.
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
