tech-kern archive

[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:

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

Any comments?


On Tue, Aug 26, 2014 at 4:28 AM, Mindaugas Rasiukevicius
<> wrote:
> Ryota Ozaki <> 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
>> solution.
> 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 [1] that may block due to copyout.
>> [1]
> 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.
> --
> Mindaugas

Home | Main Index | Thread Index | Old Index