From owner-svn-src-head@FreeBSD.ORG Mon Mar 30 10:59:17 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 381732C4; Mon, 30 Mar 2015 10:59:17 +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 93A1DCE7; Mon, 30 Mar 2015 10:59:16 +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 t2UAxEEJ043249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Mar 2015 13:59:14 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t2UAxD2F043248; Mon, 30 Mar 2015 13:59:13 +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 13:59:13 +0300 From: Gleb Smirnoff To: Hans Petter Selasky Subject: Re: svn commit: r280759 - head/sys/netinet Message-ID: <20150330105913.GF64665@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55190EA7.9010905@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 10:59:17 -0000 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? 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. 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. -- Totus tuus, Glebius.