Date: Wed, 8 Apr 2015 13:28:42 +0300 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Adrian Chadd <adrian@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r281239 - head/sys/netinet Message-ID: <20150408102842.GQ64665@FreeBSD.org> In-Reply-To: <20150408084839.GO64665@FreeBSD.org> References: <201504072309.t37N9Zwf011383@svn.freebsd.org> <20150408084839.GO64665@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150408102842.GQ64665>