Date: Mon, 30 Mar 2015 13:29:51 +0200 From: Hans Petter Selasky <hps@selasky.org> To: Gleb Smirnoff <glebius@FreeBSD.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: <551933AF.4080300@selasky.org> In-Reply-To: <20150330105913.GF64665@FreeBSD.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> <20150330105913.GF64665@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?551933AF.4080300>