svn commit: r281239 - head/sys/netinet
Gleb Smirnoff
glebius at FreeBSD.org
Wed Apr 8 10:28:47 UTC 2015
On Wed, Apr 08, 2015 at 11:48:39AM +0300, Gleb Smirnoff wrote:
T> On Tue, Apr 07, 2015 at 11:09:35PM +0000, Adrian Chadd wrote:
T> A> Author: adrian
T> A> Date: Tue Apr 7 23:09:34 2015
T> A> New Revision: 281239
T> A> URL: https://svnweb.freebsd.org/changeset/base/281239
T> A>
T> A> Log:
T> A> Move the IPv4 reassembly queue locking from a single lock to be per-bucket (global).
T> A>
T> A> This significantly improves performance on multi-core servers where there
T> A> is any kind of IPv4 reassembly going on.
T> A>
T> A> glebius@ would like to see the locking moved to be attached to the reassembly
T> A> bucket, which would make it per-bucket + per-VNET, instead of being global.
T> A> I decided to keep it global for now as it's the minimal useful change;
T> A> if people agree / wish to migrate it to be per-bucket / per-VNET then please
T> A> do feel free to do so. I won't complain.
T> A>
T> A> Thanks to Norse Corp for giving me access to much larger servers
T> A> to test this at across the 4 core boxes I have at home.
T> A>
T> A> Differential Revision: https://reviews.freebsd.org/D2095
T> A> Reviewed by: glebius (initial comments incorporated into this patch)
T>
T> No, they are not.
T>
T> Also, I just noticed another issue with the patch. You initialize the mutexes,
T> which are global, in the ip_init() which is called for every VNET. That would
T> lead to panic of initializing already initialized mutex. If you followed my advice,
T> that would not happen. Now VIMAGE+INVARIANTS is broken instantly, and w/o
T> INVARIANTS may panic if VIMAGE created under IP traffic.
T>
T> My comment that purging from a bucket that is determined by source IP has
T> security implications was also ignored.
T>
T> I will fix this all myself.
Another issue is that now V_nipq is not protected by a global lock and its
value would leak.
I'm working on a patch.
--
Totus tuus, Glebius.
More information about the svn-src-head
mailing list