Re: m_reclaim & ieee1394_drain

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

On Mon, Dec 8, 2014 at 8:31 PM, Michael van Elst <mlelstv%serpens.de@localhost> wrote:
> ozaki-r%netbsd.org@localhost (Ryota Ozaki) writes:
>
>>On Mon, Dec 8, 2014 at 6:36 PM, Michael van Elst <mlelstv%serpens.de@localhost> wrote:
>>> ozaki-r%netbsd.org@localhost (Ryota Ozaki) writes:
>>>
>>>>pr_ddain and if_drain memory reclaiming routines
>>>>are called from m_reclaim. Most of them are delayed,
>>>
>>> Where do you see if_drain routines?
>>>
>>> ./arch/arm/allwinner/awin_eth.c:        ifp->if_drain = awin_eth_ifdrain;
>>> -> a donothing routine
>>>
>>> ./net/if.c:     ifp->if_drain    = if_nulldrain;
>>> -> the official donothing routine, set when the interface gets deactivated
>>>    where setting the pointer to NULL would be ok.
>>>
>>> ./net/if_ieee1394subr.c:        ifp->if_drain = ieee1394_drain;
>>> -> the only one that does something.
>
>>I misspelled. s/pr_ddain/pr_drain/
>
>>Anyway I should say clearly that pr_drain routines are delayed
>>(such as tcp_drainstub and ip_drainstub) and only ieee1394_drain
>>is not delayed.
>
> Maybe it is better then to add the delay into the reclaim function.
> That way it doesn't need to be handled by each driver that wants
> to implement if_drain.

Hmm, I mislead you again... I meant putting ieee1394_drain out
of m_reclaim and execute it in another context (callout in this
case).

>
> Would if_drain even require a kernel_lock when it is just freeing
> memory?

I think it's still required for protecting list processing rather
than freeing memory, though it is better to use a mutex inside
ieee1394_drain for that purpose. And such locking should be out of
IFNET_FOREACH for pserialize if possible.

  ozaki-r