Date: Sat, 28 Mar 2015 11:34:43 +0300 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Fabien Thomas <fabient@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r280759 - head/sys/netinet Message-ID: <20150328083443.GV64665@FreeBSD.org> In-Reply-To: <201503271326.t2RDQxd3056112@svn.freebsd.org> References: <201503271326.t2RDQxd3056112@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 27, 2015 at 01:26:59PM +0000, Fabien Thomas wrote: F> Author: fabient F> Date: Fri Mar 27 13:26:59 2015 F> New Revision: 280759 F> URL: https://svnweb.freebsd.org/changeset/base/280759 F> F> Log: F> On multi CPU systems, we may emit successive packets with the same id. F> Fix the race by using an atomic operation. F> F> Differential Revision: https://reviews.freebsd.org/D2141 F> Obtained from: emeric.poupon@stormshield.eu F> MFC after: 1 week F> Sponsored by: Stormshield The D2141 says that benchmarking were done in presence of IPSEC, which of course is the bottleneck and performance of this instruction can't be benchmarked in its presence. Anyway, I believe that results of right benchmark would still show little difference between atomic and non-atomic increment of a shared value. I think we can use per-cpu ID counters, each CPU incrementing its own. If we start with random values, then probability of two packets with the same ID emitting at the allowed timeframe will be acceptably small. -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150328083443.GV64665>