[ovs-dev] criteria/benchmarks for an improved userspace datapath classifier?

Flavio Leitner fbl at sysclose.org
Wed Jul 3 18:08:50 UTC 2019


Hi Michal,

On Tue, Jul 02, 2019 at 10:06:47PM +0100, Michal Orsák wrote:
> Hello,
> 
> 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.

HTH,
fbl 


More information about the dev mailing list