2016/02/11 2:36 "Taylor R Campbell" <campbell+netbsd-tech-k...@mumble.net>: > > Date: Wed, 10 Feb 2016 18:56:46 +0900 > From: Ryota Ozaki <ozak...@netbsd.org> > > Thanks to introducing softint-based if_input, > we can simplify bridge(4). > > Awesome! I love patches that have loads more -'s than +'s, and > simplify locking schemes, and remove sketchy cpu_intr_p conditionals, > and things like that. > > Here is a patch: > http://www.netbsd.org/~ozaki-r/simplify-bridge.diff > > Remove cpu_intr_p from BRIDGE_RT_RENTER/REXIT too?
Definitely I forgot them :-/ Fixed. > > I wonder how much of a difference BRIDGE_MPSAFE really makes on > uniprocessor systems. If this were new code I wouldn't have done any > conditional compilation of that. I can't imagine the performance > impact is very high: maybe a few more words of memory are used, but > uniprocessor mutex acquisition should be pretty cheap. Maybe in a > future patch we can eliminate all that. I agree. I'll do that soon. BTW, currently softints of a percpuq is SOFTINT_MPSAFE so they can run in parallel even now if a underlying driver supports multi-queue (now only wm(4) supports it though). On that reason, I think we should always enable bridge(4) MP-safe codes and add KERNEL_LOCK to vlan(4) for safe. (Or remove SOFTINT_MPSAFE at this point.) > Hmm... Another note, not related to your patch: queue(3) does not > issue the necessary memory barriers for pserialization. So the use of > LIST_* for rtlist and iflist is not actually safe here -- I imagine it > has worked only by accident before. > > Either we need to make a variant of queue(3) that is pserialize-safe > (https://mail-index.netbsd.org/tech-kern/2014/11/21/msg018055.html) or > open-code it here. (rmind@ objected to a pserialize-safe queue(3) in > favour of just open-coding it in the few places where it's needed. I > don't think that's a good idea but I didn't care to take on that fight > at the time.) I prefer that such fundamental requirements are guaranteed by the API. Users (including me) of pserialize aren't always expert on memory barriers (of every CPU architectures!). Thanks, ozaki-r
