Re: RFC: gif(4) MP-ify

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

Hi riastradh@n.o, 

On 2015/12/26 23:47, Taylor R Campbell wrote:
>    Date: Fri, 25 Dec 2015 17:49:35 +0900
>    From: Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>
> 
>    I MP-ify gif(4) interface and ip_encap which is required by gif(4).
> 
>    Here is the patch
>        http://www.netbsd.org/~knakahara/gif-mp-ify/gif-mp-ify.patch
> 
>    Could you comment this patch?
> 
> I see a lot of rwlocks.  Can you describe the access patterns you
> expect for these -- what operations require reader or writer locks,
> how often are these operations done, and what contention you expect?

I expect the following access patterns ideally.
    - receive processing and transmit processing use reader locks
    - setter ioctls processing (such as "ifconfig tunnel" and
      "ifconfig deletetunnel") use writer locks

I think setter ioctls are rarely done during receive and transmit
processing over gif(4) is running. Usual operations must be the
following.
    - stop receive and transmit processing
    - change gif(4) configuration
    - restart receive and transmit processing

I expect the following contention.
    - multiple receive processing / multiple transmit processing
      => these can run parallel holding reader locks (GIF_READ_LOCK() or
         ENCAP_WHOLE_READ_LOCK())
    - receive(or transmit) processing / ifconfig gifX tunnel "src" "dst"
      => these are serialized by GIF_WRITE_LOCK() or ENCAP_WHOLE_WRITE_LOCK()
         of ifconfig gifX tunnel "src" "dst"
    - ifconfig gifX tunnel "src" "dst" / ifconfig gifX destroy
      => these are serialized by GIF_LIST_WRITE_LOCK() of
         ifconfig gifX destroy
note:
    - ifconfig gifX tunnel "src" "dst" / ifconfig gifX deletetunnel "src" "dst"
      => these are serialized by ifnet_lock_enter() in doifioctl()@sys/net/if.c

> For large and complex operations, it may be worthwhile to allow
> multiple readers by using an rwlock.  But reader locks still have high
> contention to acquire and release.  So if we want an MP-scalable, not
> merely MP-safe, network stack, I wonder whether it might be better to
> use pserialize(9) instead of rwlock in some cases here -- or a
> pserialize(9)-based rwlock, like fstrans.

I agree. But, I think it may be future works because there are more
weighty bottlenecks such as if_snd queues and softnet_lock()...

Anyway, it should use pserialize(9), so I try to rework with
pserialize(9).


Thanks,

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

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

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