Date: Fri, 7 Feb 2014 17:12:56 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Ryan Stone <rysto32@gmail.com> Cc: FreeBSD Net <freebsd-net@freebsd.org>, Adrian Chadd <adrian@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: flowtable, collisions, locking and CPU affinity Message-ID: <20140208011256.GH89104@funkthat.com> In-Reply-To: <CAFMmRNyYFte0Q5Jhw0A3Fkya9d8hQ-22pRHYZE62pB_wKb9Caw@mail.gmail.com> References: <CAJ-VmonNCzFED=20_C2fV1g1jvFNRE=N-H%2B09Wb2OdxdzHp9JQ@mail.gmail.com> <CAFMmRNyYFte0Q5Jhw0A3Fkya9d8hQ-22pRHYZE62pB_wKb9Caw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ryan Stone wrote this message on Fri, Feb 07, 2014 at 20:05 -0500:
> On Fri, Feb 7, 2014 at 7:12 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> > In any case - the reason it's happening above is because there's no
> > actual lock held over the whole lookup/insert path. It's a per-CPU
> > critical enter/exit path, so the only way to guarantee consistency is
> > to use sched_pin() for the entirety of the function.
>
> sched_pin seems like a very heavy hammer for what has to be a very
> rare and mostly harmless race. Why not redo the lookup after you have
> reacquired the lock, and if you don't have to do the insert anymore
> then don't and move on?
Why not drop the work since the current CPU has the results? It sucks
to throw away work, but the other option is to remeber what cpu you
were on, and put it there, but that would also be expensive...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140208011256.GH89104>