Date: Fri, 7 Feb 2014 20:05:57 -0500 From: Ryan Stone <rysto32@gmail.com> To: Adrian Chadd <adrian@freebsd.org> Cc: FreeBSD Net <freebsd-net@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: flowtable, collisions, locking and CPU affinity Message-ID: <CAFMmRNyYFte0Q5Jhw0A3Fkya9d8hQ-22pRHYZE62pB_wKb9Caw@mail.gmail.com> In-Reply-To: <CAJ-VmonNCzFED=20_C2fV1g1jvFNRE=N-H%2B09Wb2OdxdzHp9JQ@mail.gmail.com> References: <CAJ-VmonNCzFED=20_C2fV1g1jvFNRE=N-H%2B09Wb2OdxdzHp9JQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFMmRNyYFte0Q5Jhw0A3Fkya9d8hQ-22pRHYZE62pB_wKb9Caw>