> On Mar 17, 2014, at 6:57 PM, Joe Stringer <joestrin...@nicira.com> wrote: > >> 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.
There would be more improvement if we were able to shift resources saved in revalidation to miss handling, as in reducing the number of revalidator threads and correspondingly increasing the number of handler threads. Jarno
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
