Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 30 Mar 2015 13:59:13 +0300
From:      Gleb Smirnoff <glebius@FreeBSD.org>
To:        Hans Petter Selasky <hps@selasky.org>
Cc:        Adrian Chadd <adrian@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, Ian Lepore <ian@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, Fabien Thomas <fabient@freebsd.org>
Subject:   Re: svn commit: r280759 - head/sys/netinet
Message-ID:  <20150330105913.GF64665@FreeBSD.org>
In-Reply-To: <55190EA7.9010905@selasky.org>
References:  <201503271326.t2RDQxd3056112@svn.freebsd.org> <20150328083443.GV64665@FreeBSD.org> <20150328191629.GY64665@FreeBSD.org> <5517B433.5010508@selasky.org> <CAJ-VmonU15_nEGVQNwR52deDf1TbPUz0oAMr%2B3zwNqU_9%2Bo1fw@mail.gmail.com> <20150329210757.GA64665@FreeBSD.org> <1427666182.82583.4.camel@freebsd.org> <55190EA7.9010905@selasky.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150330105913.GF64665>