From owner-svn-src-head@FreeBSD.ORG Mon Mar 30 12:07:08 2015 Return-Path: Delivered-To: svn-src-head@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 DF21F27B; Mon, 30 Mar 2015 12:07:08 +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 469476CE; Mon, 30 Mar 2015 12:07:07 +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 t2UC75wR043680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Mar 2015 15:07:05 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t2UC70n8043678; Mon, 30 Mar 2015 15:07:00 +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 15:07:00 +0300 From: Gleb Smirnoff To: Hans Petter Selasky Subject: Re: svn commit: r280759 - head/sys/netinet Message-ID: <20150330120700.GH64665@FreeBSD.org> References: <201503271326.t2RDQxd3056112@svn.freebsd.org> <20150328083443.GV64665@FreeBSD.org> <20150328191629.GY64665@FreeBSD.org> <5517B433.5010508@selasky.org> <20150329210757.GA64665@FreeBSD.org> <1427666182.82583.4.camel@freebsd.org> <55190EA7.9010905@selasky.org> <20150330105913.GF64665@FreeBSD.org> <551933AF.4080300@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <551933AF.4080300@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Adrian Chadd , "src-committers@freebsd.org" , Ian Lepore , "svn-src-all@freebsd.org" , "svn-src-head@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: Mon, 30 Mar 2015 12:07:09 -0000 Hans, On Mon, Mar 30, 2015 at 01:29:51PM +0200, Hans Petter Selasky wrote: H> You don't get it fully. Every time a CPU runs out of IDs, it allocates a H> new 256 long series of numbers. That way the CPUs allocate numbers in H> sequence. H> H> > The suggested code suffers from migration more than what I suggested. E.g. H> > you can assign V_ip_id_start on CPU 1 then migrate to CPU 2 and assign H> > V_ip_id_end, yielding in the broken state of the ID generating machine. H> > Or you can compare start and end on different CPUs, which causes less harm. H> H> Surely we need to add the critial_enter() and critical_exit() around H> this code, it is just meant as an example. Making the function heavier and heavier, trying to reduce the probability of an event that already happens naturally orders of magnitude more often, than we can can trigger it with our code. H> > And still the code doesn't protect against full 65k overflow. One CPU H> > can emit a burst over 65k packets, and then go on and reuse all the IDs H> > that other CPUs are using now. H> > H> H> Given sending 65K packets will take some time, using a shared atomic H> operation will slow down this wraparound more than if it was per CPU. If H> this is an argument, why do you want to make the ID allocation faster H> and not slower? Should there perhaps be a DELAY() in there if too many H> IDs rush out too quickly? DELAY() into network stack? Are you serious now or kidding me? -- Totus tuus, Glebius.