From owner-svn-src-all@FreeBSD.ORG Sat Mar 28 20:43:35 2015 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1906CB18; Sat, 28 Mar 2015 20:43:35 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E6BD7763; Sat, 28 Mar 2015 20:43:34 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t2SKhX9K040665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Mar 2015 13:43:33 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t2SKhX48040664; Sat, 28 Mar 2015 13:43:33 -0700 (PDT) (envelope-from jmg) Date: Sat, 28 Mar 2015 13:43:33 -0700 From: John-Mark Gurney To: Gleb Smirnoff Subject: Re: svn commit: r280759 - head/sys/netinet Message-ID: <20150328204333.GF51048@funkthat.com> References: <201503271326.t2RDQxd3056112@svn.freebsd.org> <20150328083443.GV64665@FreeBSD.org> <20150328172313.GC51048@funkthat.com> <20150328181833.GX64665@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150328181833.GX64665@FreeBSD.org> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Sat, 28 Mar 2015 13:43:34 -0700 (PDT) Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Fabien Thomas X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 20:43:35 -0000 Gleb Smirnoff wrote this message on Sat, Mar 28, 2015 at 21:18 +0300: > On Sat, Mar 28, 2015 at 10:23:13AM -0700, John-Mark Gurney wrote: > J> > On Fri, Mar 27, 2015 at 01:26:59PM +0000, Fabien Thomas wrote: > J> > F> Author: fabient > J> > F> Date: Fri Mar 27 13:26:59 2015 > J> > F> New Revision: 280759 > J> > F> URL: https://svnweb.freebsd.org/changeset/base/280759 > J> > F> > J> > F> Log: > J> > F> On multi CPU systems, we may emit successive packets with the same id. > J> > F> Fix the race by using an atomic operation. > J> > F> > J> > F> Differential Revision: https://reviews.freebsd.org/D2141 > J> > F> Obtained from: emeric.poupon@stormshield.eu > J> > F> MFC after: 1 week > J> > F> Sponsored by: Stormshield > J> > > J> > The D2141 says that benchmarking were done in presence of IPSEC, which > J> > of course is the bottleneck and performance of this instruction can't > J> > be benchmarked in its presence. Anyway, I believe that results of > J> > right benchmark would still show little difference between atomic and > J> > non-atomic increment of a shared value. > J> > > J> > I think we can use per-cpu ID counters, each CPU incrementing its > J> > own. If we start with random values, then probability of two packets with > J> > the same ID emitting at the allowed timeframe will be acceptably small. > J> > J> Please do not use per-cpu id counters.. That will just push the > J> duplicate ids to being more rare, but just as much of a problem... > J> > J> Please read: > J> https://tools.ietf.org/html/rfc6864 > J> > J> And then implement one hased upon source/dest/protocol... > > I know about this RFC, but using per-cpu ID counter if a low hanging > fruit and is improvement. What is important not only improvement in > terms of lowering probability of collision, but also easy improvement in > performance, since now global ip_id increment is a cache line thrasher. > > So, I don't see how existense of the RFC blocks introducing an easy > improvement. And if anyone works on implementing the RFC, he shouldn't > care what is in head before his work, either global or per-cpu counter. Your comment: "fix the race", to me reads that it was a final solution, not simply a stop gap... If you had simply said that this is a stop gap till someone properly implements RFC6864, that would make it obvious that you were aware of it.. Nothing in your commit message said that you were aware that this wasn't the correct final solution... Information like that should be included in the commit message so people don't assume that this is the final solution... Anyways, are we really sending so many fragments that we are thrashing the cache line? I'd imagine a much lower hanging fruit is only provide ip_id when a non-atomic packet is being sent... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."