[ovs-dev] criteria/benchmarks for an improved userspace datapath classifier?
fbl at sysclose.org
Wed Jul 3 18:08:50 UTC 2019
On Tue, Jul 02, 2019 at 10:06:47PM +0100, Michal Orsák wrote:
> On 02/07/2019 19:47, Flavio Leitner wrote:
> > On Tue, Jul 02, 2019 at 10:00:44AM -0700, Ben Pfaff wrote:
> > > Hi Ilya and Ian. Please allow me to introduce Michal Orsak, a grad
> > > student currently looking at packet classifiers. He's implemented a
> > > novel classifier that is faster than the one already in OVS in the
> > > benchmarks that he's run. His classifier is tree-based, like most
> > > high-performance classifiers, but also incremental so that flows can be
> > > inserted and deleted individually without undue delay. Ultimately, it
> > > might make sense to replace the OVS userspace datapath classifier by one
> > > based on the concepts that he's come up with.
> > >
> > > A difficulty with classifiers, however, is coming up with an appropriate
> > > set of benchmarks to compare them fairly. The userspace datapath
> > > focuses on performance, so do you have a set of benchmarks that you
> > > recommend for comparison? Are there other criteria that would be
> > > important (besides correctness)?
> > >
> > > (I'd take answers from anyone, not just Ian and Ilya!)
> > Hi Ben,
> > We use 1M constant IPv4 flows, and 200k new and 200k retiring IPv4
> > flows per second to compare as it seems to be close to some production
> > workloads.
> What is the format of the rules in classifier?
Sorry for my quick reply. It's a good question. Most deployments I am
aware of use OpenStack and depending on the version you might have security
groups and etc... otherwise it is the action NORMAL, so it wouldn't stress
test insertion/deletion in this case.
> Do you also remove and add 200K rules/s?
No, the flow table is pretty "static", or better, a function of how many
VMs and tunnels are running.
I guess you need a good flow table and a traffic pattern see if it
improves or not. What I am suggesting is a traffic pattern we learned
from the field in a deployment that at least we should not regress on.
More information about the dev