netdev - Re: Integration of Open vSwitch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111201075134.GB18436@verge.net.au>
Date:	Thu, 1 Dec 2011 16:51:38 +0900
From:	Simon Horman <horms@...ge.net.au>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	jhs@...atatu.com, Jesse Gross <jesse@...ira.com>,
	netdev <netdev@...r.kernel.org>, dev@...nvswitch.org,
	David Miller <davem@...emloft.net>,
	Stephen Hemminger <shemminger@...tta.com>,
	Chris Wright <chrisw@...hat.com>,
	John Fastabend <john.r.fastabend@...el.com>,
	Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: Integration of Open vSwitch

On Wed, Nov 30, 2011 at 09:40:28PM +0800, Herbert Xu wrote:
> On Wed, Nov 30, 2011 at 08:14:51AM -0500, jamal wrote:
> > On Wed, 2011-11-30 at 15:00 +0800, Herbert Xu wrote:
> > 
> > 
> > > The other factor I considered is scalability.  The OVS code as is
> > > is not really friendly to SMP/NUMA scalability (but as Eric pointed,
> > > neither is the classifier/action layer). 
> > 
> > Did you mean the qdisc funnel-to-interface part which Eric is hopefully
> > going to work on now that bql is in? classifier/action happens way
> > before that.
> 
> I actually meant the scalability with adding/deleting flows,
> or in the case with qdiscs, filters.
> 
> OVS is quite scalable on the fast-path, but when it comes to
> new flows, you have a bottleneck.

Having done some testing of OVS in relation to both the
number of flows I can stuff into the system and how fast I can do so,
I agree.

As it stands I don't believe that there has been a whole lot
of work so far on optimising for high rates of new flows. I say
this based on a low-hang optimisations I have found (and discussed
on the OVS dev list).

Obviously at some point the low-hanging fruit can all be picked and
making things faster becomes more difficult. And it seems to me
that the user-space controller is only single threaded and that
is a significant bottle-neck to scaling flow creation beyond some point.

But I also suspect there are lot of use-cases for OVS where the
current code scales sufficiently.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html