Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

On Tue, Nov 18, 2014 at 12:36 PM, Masao Uebayashi <uebayasi%gmail.com@localhost> wrote:
> On Tue, Nov 18, 2014 at 11:24 AM, Ryota Ozaki <ozaki-r%netbsd.org@localhost> wrote:
>> First I'm not against restructuring, though I hoped minimum
>> restructuring on non-performance-sensitive paths.
>
> My understanding is that, non-performance-sensitive paths (e.g.
> ioctl()'s) also touches performance-sensitive data structures (e.g.
> ifnet list), that is the problem.  Non-performance-sensitive paths
> have to be more careful to not disturb performance-sensitive data
> structures and paths.  For ioctl()'s, they have to allocate
> kernel-wired memory to not sleep (via copyout()) while iterating
> performance-critical ifnet list.  Thus I don't think you can avoid
> restructuring those codes.

pserialize can prevent slow paths (IFNET_LOCK) from disturbing
fast paths (IFNET_RENTER) because IFNET_RENTER (pserialize_read_enter)
is just a splsoftserial and can run regardless of IFNET_LOCK.
Of course slow paths including ioctl() can work against each other.

>
> (I'd want to also encourage you to *not* become too nervous about
> changing those codes.  Let's progress bravely and rely on high-quality
> NetBSD "end" users for testing. :)

You know well :) I'm now positive to do so. Thanks!

  ozaki-r

>
>> BTW, do you think we eventually introduce "all packet processing in
>> a LWP context"-like restructuring? I'm inclined to run Layer2 and bpf
>> in softint. If we also end up doing so, I want to do it early.
>> Of course, we have to address performance issues somehow at some point
>> though.
>>
>> Thanks,
>>   ozaki-r
>>
>>>
>>> Dave
>>>
>>> --
>>> David Young
>>> dyoung%pobox.com@localhost    Urbana, IL    (217) 721-9981