[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]
I'm back to the work.
Here is a new patch: http://www.netbsd.org/~ozaki-r/psz-ifnet.diff
I think the patch reflects rmind's suggestions:
- Use pserialize for IFNET_FOREACH
- but use a lock for blockable/sleepable critical sections
- cpu_intr_p workaround for HW interrupt
On Tue, Aug 26, 2014 at 4:28 AM, Mindaugas Rasiukevicius
> Ryota Ozaki <ozaki-r%NetBSD.org@localhost> wrote:
>> > I generally agree with Dennis that is not the way we want to take in
>> > the long-term. The cost of read-write lock is very high. The plan
>> > is to use passive serialisation to protect the interfaces and their
>> > addresses. Also, the ultimate goal would also be to use a better
>> > data structure (linked lists are not really efficient) and change the
>> > way interfaces are referenced i.e. instead of referencing ifnet_t,
>> > the network stack should use a unique ID.
>> I have no objection to the direction. My concern is an intermediate
> Right, but I think we can still avoid read-write lock for the intermediate
> solution. ID based interface referencing requires a greater revamp.
>> > Note that the code paths
>> > looking up the interface or its address(es) should not block (if they
>> > do, the code can be rearranged).
>> Some codes under sys/compat can be blocked during the iterations,
>> for example linux_getifconf at  that may block due to copyout.
> Yes, but it is not performance sensitive path. You can acquire the lock
> used on the pserialize(9) writer side. Basically, we need to optimise the
> IP input/output paths; the rest can be heavy-locked for now.
>> > Also, in the long run, ifnet list
>> > should not be accessed from the hard interrupt context -- all users
>> > ought to be running in the softintr(9) context.
>> The ifnet list is accessed in m_reclaim that may be called from
>> hardware interrupt context via say MCL_GET.
> Yes, but my point was that we should eliminate the access of ifnet list,
> as well as other network stack structures, from the hard interrupt. This
> means converting the existing code to use softintr(9). In the long term,
> the drivers should always trigger softintr(9) and L2 never be called from
> the hard interrupt context. As for m_reclaim(9), we might workaround it
> with a test on cpu_intr_p() for now.
>> > We may need to take an intermediate solution, but I think we can
>> > already switch to pserialize(9) + reference counting on ifnet_t for
>> > the ip_input/ip_output() paths. I need to resume my work on the
>> > routing subsystem patch-up, though.
>> I think we need to get rid of blockable operations mentioned the above.
> Or just treat them as writers.
Main Index |
Thread Index |