From owner-svn-src-all@FreeBSD.ORG Mon Mar 30 12:37:27 2015 Return-Path: Delivered-To: svn-src-all@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 D2844A12; Mon, 30 Mar 2015 12:37:27 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8928EA4F; Mon, 30 Mar 2015 12:37:27 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 5E5121FE023; Mon, 30 Mar 2015 14:37:25 +0200 (CEST) Message-ID: <551943B4.90102@selasky.org> Date: Mon, 30 Mar 2015 14:38:12 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: svn commit: r280759 - head/sys/netinet 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> <20150330120700.GH64665@FreeBSD.org> In-Reply-To: <20150330120700.GH64665@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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-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: Mon, 30 Mar 2015 12:37:28 -0000 On 03/30/15 14:07, Gleb Smirnoff wrote: > 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? > Hi Gleb, Should the IPv4 ID field carry useful information or not? > DELAY() into network stack? Are you serious now or kidding me? If there should be any useful meaning in the 16-bit IP ID field, the value can't be allowed to wrap several times in a millisecond. Given the context from where the network code is running, msleep() is not an option. A _conditional_ DELAY() of 1-2 us, is maybe all we need to prevent the value from wrapping too quickly. It is not perfect and it is indeed consuming more CPU. Or maybe we can add an IPv4 option to escape a 32-bit IP ID field and don't use the 16-bit IP ID field. --HPS