From owner-svn-src-head@FreeBSD.ORG Sun Mar 29 21:15:37 2015 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D21F195; Sun, 29 Mar 2015 21:15:37 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 75A76AC1; Sun, 29 Mar 2015 21:15:36 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t2TLFYQm039744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Mar 2015 00:15:34 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t2TLFXCd039743; Mon, 30 Mar 2015 00:15:33 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 30 Mar 2015 00:15:33 +0300 From: Gleb Smirnoff To: John-Mark Gurney Subject: Re: svn commit: r280759 - head/sys/netinet Message-ID: <20150329211533.GB64665@FreeBSD.org> References: <201503271326.t2RDQxd3056112@svn.freebsd.org> <20150328083443.GV64665@FreeBSD.org> <20150328172313.GC51048@funkthat.com> <20150328181833.GX64665@FreeBSD.org> <20150328204333.GF51048@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150328204333.GF51048@funkthat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Fabien Thomas X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 21:15:37 -0000 On Sat, Mar 28, 2015 at 01:43:33PM -0700, John-Mark Gurney wrote: J> > J> > I think we can use per-cpu ID counters, each CPU incrementing its J> > J> > own. If we start with random values, then probability of two packets with J> > J> > the same ID emitting at the allowed timeframe will be acceptably small. J> > J> J> > J> Please do not use per-cpu id counters.. That will just push the J> > J> duplicate ids to being more rare, but just as much of a problem... J> > J> J> > J> Please read: J> > J> https://tools.ietf.org/html/rfc6864 J> > J> J> > J> And then implement one hased upon source/dest/protocol... J> > J> > I know about this RFC, but using per-cpu ID counter if a low hanging J> > fruit and is improvement. What is important not only improvement in J> > terms of lowering probability of collision, but also easy improvement in J> > performance, since now global ip_id increment is a cache line thrasher. J> > J> > So, I don't see how existense of the RFC blocks introducing an easy J> > improvement. And if anyone works on implementing the RFC, he shouldn't J> > care what is in head before his work, either global or per-cpu counter. J> J> Your comment: "fix the race", to me reads that it was a final solution, J> not simply a stop gap... J> J> If you had simply said that this is a stop gap till someone properly J> implements RFC6864, that would make it obvious that you were aware of J> it.. Nothing in your commit message said that you were aware that this J> wasn't the correct final solution... Information like that should be J> included in the commit message so people don't assume that this is the J> final solution... J> J> Anyways, are we really sending so many fragments that we are thrashing J> the cache line? I'd imagine a much lower hanging fruit is only provide J> ip_id when a non-atomic packet is being sent... I didn't do a commit that enables discussed feature. What commit message do you refer to? Well, if you are sure that implementing RFC6864 is a much lower hanging fruit than the patch, that I submitted to the list, then you are welcome to implement it. :) As for me, it requires to examine the stack a bit to be sure that we aren't missing anything important. -- Totus tuus, Glebius.