netdev - Re: [GIT PULL v2] 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: <20111201072418.GA18436@verge.net.au>
Date:	Thu, 1 Dec 2011 16:24:18 +0900
From:	Simon Horman <horms@...ge.net.au>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	Jesse Gross <jesse@...ira.com>,
	"Fischer, Anna" <anna.fischer@...com>,
	"jhs@...atatu.com" <jhs@...atatu.com>,
	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"dev@...nvswitch.org" <dev@...nvswitch.org>
Subject: Re: [GIT PULL v2] Open vSwitch

On Wed, Nov 30, 2011 at 03:02:19PM +0800, Herbert Xu wrote:
> On Tue, Nov 29, 2011 at 10:21:32PM -0800, Jesse Gross wrote:
> >
> > It's userspace which is managing the entries in the kernel hash table
> > and it has some intelligence about aging out entries (and specifically
> > about doing it more aggressively as the number of entries increases),
> > so it's not really unbounded.  In practice, userspace actually keeps
> > the number of entries much smaller than the maximum size of the table.
> 
> Right, I thought you would have something like this.
> 
> But I think you still need to rehash the table periodically, as
> otherwise even with a limited number of entries and attacker could
> construct long chains in a hash bucket, given enough time.

I have done some work on both testing and improving the performance
of Open vSwitch with large number of flows (for some definition of large).

My current opinion is that expanding the hash table beyond its current
maximum size does not seem to yield a performance benefit.  This is
primarily because there are other performance issues that come into play
first - in particular the rate at which a dump of statistics for all flows
is made (I intend to fix this, its a user-space problem).

So while I agree that optimizing the hash is a good idea.  I don't believe
it is a bottle-neck at this point. Though I could be convinced otherwise if
long collision chains could be constructed with relatively few flows.
Something I had not considered until I rad your email just now.

--
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