[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]
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!
>> 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
>>> David Young
>>> dyoung%pobox.com@localhost Urbana, IL (217) 721-9981
Main Index |
Thread Index |