flowtable, collisions, locking and CPU affinity

John-Mark Gurney jmg at funkthat.com
Sat Feb 8 01:13:02 UTC 2014


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 at 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."


More information about the freebsd-arch mailing list