Re: RFC: gif(4) MP-ify

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

   Date: Tue, 12 Jan 2016 18:54:44 +0900
   From: Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>

   Yes, I removed atomic operations from gif(4) packet-processing path,
   as note above. I think the fix for PR/50522 fixes the race between
   gif_output and softint_disestablish.

Ah, OK, I missed that -- joerg@'s Git mirror, which I often use for
faster browsing of history, is not up-to-date.  I sent you another
message on that subject.

   Hmm... ip_encap.c(encap_attach and encap_detach) is used by
   not only gif(4) but also stf(4) for now, so I think the global
   interruptible lock might be the common lock among gif(4), stf(4)
   and other interfaces which will use ip_encap.c.

   Except it, the processing seems excellent.

I think you could avoid a lot of work if there were an easy way to fix
the XXX comment in encap6_ctlinput:

		/* XXX need to pass ep->arg or ep itself to listeners */
		psw = (const struct ip6protosw *)ep->psw;
		if (psw && psw->pr_ctlinput)
			(*psw->pr_ctlinput)(cmd, sa, d);

This seems to be the only reason why ip6_gif_ctlinput needs to use
gif_softc_list -- and the only reason why gif_softc_list is exposed
from if_gif.c at all.

One way you might do this is to stop using struct protosw for the
callbacks in encap, and just invent a different struct encapsw, with a
ctlinput callback that takes an extra argument.  I *think* only
pr_input and pr_ctlinput are used here.

   I feel like avoiding KERNEL_LOCK... I will implement based on the sketch.

It is nice to avoid KERNEL_LOCK, but there are bigger fish to fry in
the packet-processing path first.  So I wouldn't worry too much about
this first unless you really like debugging concurrency abstractions!