From owner-svn-src-head@FreeBSD.ORG Mon Mar 30 11:29:06 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 8C9497B3; Mon, 30 Mar 2015 11:29:06 +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 456FEFE4; Mon, 30 Mar 2015 11:29:06 +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 E8CDD1FE023; Mon, 30 Mar 2015 13:29:03 +0200 (CEST) Message-ID: <551933AF.4080300@selasky.org> Date: Mon, 30 Mar 2015 13:29:51 +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> In-Reply-To: <20150330105913.GF64665@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-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 11:29:06 -0000 On 03/30/15 12:59, Gleb Smirnoff wrote: > On Mon, Mar 30, 2015 at 10:51:51AM +0200, Hans Petter Selasky wrote: > H> Hi, > H> > H> Like was mentioned here, maybe we need a global counter that is not > H> accessed that frequently, and use per-cpu counters for the most frequent > H> accesses. To keep the order somewhat sane, we need a global counter: > H> > H> Pseudo code: > H> > H> static int V_ip_id; > H> > H> PER_CPU(V_ip_id_start); > H> PER_CPU(V_ip_id_end); > H> > H> static uint16_t > H> get_next_id() > H> { > H> if (PER_CPU(V_ip_id_start) == PER_CPU(V_ip_id_end)) { > H> next = atomic_add32(&V_ip_id, 256); > H> V_ip_id_start = next; > H> V_ip_id_end = next + 256; > H> } > H> id = V_ip_id_start++; > H> return (id); > H> } > > What's the rationale of the code? Trying to keep CPUs off by 256 from > each other? Hi, You don't get it fully. Every time a CPU runs out of IDs, it allocates a new 256 long series of numbers. That way the CPUs allocate numbers in sequence. > The suggested code suffers from migration more than what I suggested. E.g. > you can assign V_ip_id_start on CPU 1 then migrate to CPU 2 and assign > V_ip_id_end, yielding in the broken state of the ID generating machine. > Or you can compare start and end on different CPUs, which causes less harm. Surely we need to add the critial_enter() and critical_exit() around this code, it is just meant as an example. > > And still the code doesn't protect against full 65k overflow. One CPU > can emit a burst over 65k packets, and then go on and reuse all the IDs > that other CPUs are using now. > Given sending 65K packets will take some time, using a shared atomic operation will slow down this wraparound more than if it was per CPU. If this is an argument, why do you want to make the ID allocation faster and not slower? Should there perhaps be a DELAY() in there if too many IDs rush out too quickly? --HPS