Re: fix gif(4)'s softint(9) contract violation [was Re: RFC: gif(4) MP-ify]

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

   Date: Mon, 25 Jan 2016 13:41:20 +0900
   From: Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>

   On 2016/01/23 1:29, Taylor R Campbell wrote:
   > 1. fix the softint disestablish issue by adding a pause operation, and
   > 2. make ip_encap MP-scalable by using a pserialized list instead of a
   > giant-locked radix tree.
   > 
   > Part (1) can be done a little more easily, I think -- I've attached a
   > compile-tested patch that does only part (1), by calling encap_detach
   > before softint_disestablish.  It doesn't seem to require any special
   > cooperation from gif_output or gifintr.  I probably overlooked
   > something, though.

   Hum...sorry, I think I don't understand your intent. Could you tell me
   how encap_detach() stops softint_schedule() in gif_output()?
   I think gif(4)'s transmission path is not related to ip_encap.c.

You're absolutely right -- I confused the input and output paths!
Sorry for the noise.  Your patch looks fine to me, then.  I would
suggest committing part (1) separately from the rest.  One minor,
inconsequential nit for part (1): there's no need for membar_sync in
gif_encap_pause, because xc_broadcast/xc_wait serves as a full memory
barrier anyway.

   > Do you have a plan for how to address scaling to many tunnels too?

   # As you point out in the other mail, the radix tree does not help
   # much to scale to many tunnels. However, it reduces processing per
   # loop, so it helps to scale by some measures. I think it is required
   # to fix the scaling to many tunnels issue anyway.

   Yes. I plan to use hash table to search a match tunnel if possible.
   As far as gif(4), I *think* the prio check is not required. I think
   it is satisfied by psrc and pdst exact match like OpenBSD's gif(4).
   If prio check is not required in fact, it can use hash table.

Here's my quick survey of uses:

- gif(4) requires exact src/dst match and returns prio 2*32 or 2*128
- stf(4) requires exact src match and returns prio 32
- ip_mroute.c requires exact src/dst match and returns prio 2*32 + 5
- xform_ipip.c requires only M_IPSEC and returns prio 1

So for systems with only gif tunnels, an exact-match table suffices,
but that is not so for the three other kinds of tunnels.