Re: Simplify bridge(4)

[Ryota Ozaki <ozaki.ryota%gmail.com@localhost>]

2016/02/11 2:36 "Taylor R Campbell" <campbell+netbsd-tech-kern%mumble.net@localhost>:
>
>    Date: Wed, 10 Feb 2016 18:56:46 +0900
>    From: Ryota Ozaki <ozaki-r%netbsd.org@localhost>
>
>    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