[ovs-dev] [PATCH v4 3/9] test-classifier: Add benchmark.
jrajahalme at nicira.com
Fri Aug 21 20:18:00 UTC 2015
> On Aug 21, 2015, at 7:37 AM, Ben Pfaff <blp at 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.
> 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 <blp at nicira.com>
Thanks for the review, pushed to master,
More information about the dev