Re: RFC: gif(4) MP-ify

[Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>]

Hi,

On 2016/01/13 4:38, Taylor R Campbell wrote:
>    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.

BTW, do you know this git mirror?
    https://github.com/IIJ-NetBSD/netbsd-src

This git mirror usually sync with cvs repository every two hours.


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

Yes, only in6_gif_ctlinput() use gif_softc_list in in6_gif.c.
I will consider to remove gif_softc_list from in6_gif.c such as the way
you point out.

BTW, if we can remove rtcache, in6_gif_ctlinput itself can be removed.
Furthermore, it can more simply packet-processing path to remove rtcache.
However, of course, it may cause performance degradation. I think rtcache
should be removed and fix performance degradation by some other way.
Do you have any idea about rtcache?


>    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!

I don't like debugging concurrency abstractions. :)
I will use KERNEL_LOCK until packet-processing path stabilize.


Thanks,

-- 
//////////////////////////////////////////////////////////////////////
Internet Initiative Japan Inc.

Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit

Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>