> On Aug 21, 2015, at 7:37 AM, Ben Pfaff <b...@nicira.com> wrote: > > On Fri, Aug 07, 2015 at 04:57:36PM -0700, Jarno Rajahalme wrote: >> Add a benchmark command for classifier lookup performance testing. >> >> Usage: > > This usage note is good, but putting it just in the commit log will mean > that it gets lost. It should be in a --help message, or failing that in > a source code comment. >
I the usage (without the explanation after the itemized list and example) to “ovstest test-classifier benchmark". The usage is shown if “—help” is given as an argument, or if there are less than the required five arguments. I also added a ‘—help’ command to the test-classifier itself. > I'm not sure I believe in the realism of random priorities. Random > priorities are are worst case for the optimization that skips subtables > based on priorities. Our NSDI paper showed that subtables tend to have > a small number of priorities (often just one) in practice. > Right, thats why I made the number of priorities an option, in a lack of a better model of a “typical classifier table”. I changed the example in the commit message to use only one priority. More significantly, this is not a pipeline test, but a test on a single classifier instance. Typical pipelines would likely have only a small number of subtables in a single classifier, and would also amortize the cost of clearing ‘wc’ across multiple lookups/resubmits. > If n_rules < n_subtables, or if the random numbers come out just right, > then I think that the classifier will have fewer than the requested > number of subtables. Also, if the same rule is generated more than > once, the classifier will have fewer than the requested number of rules. > The value in the benchmark is in being able to repeat the same test (same arguments -> same test) across different classifier code variations, and maybe across different C compilers and compiler options. It clearly shows the benefit of compiling with “-march=native”, for example (with modern CPUs). The exact number of rules or subtables is less important, IMO, but obviously the code could be improved in these regards. > Acked-by: Ben Pfaff <b...@nicira.com> Thanks for the review, pushed to master, Jarno _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
