Re: m_reclaim & ieee1394_drain

[mlelstv%serpens.de@localhost (Michael van Elst)]

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.

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