Re: [PATCH] neighbour.c: Avoid GC directly after state change

["YOSHIFUJI Hideaki/吉藤英明" <hideaki.yoshifuji@miraclelinux.com>]

Hi,

Ulf Samuelsson wrote:
> Den 2015-03-12 19:26, David Miller skrev:
>> I hate changes like this.
>>
>> By making this a Kconfig options it cannot be dynamic, and every
>> distribution is going to have to scratch their head and decide
>> what to set this to.
>>
>> That's seriously suboptimal.
>>
>> If you want to change behavior based upon whether userspace is
>> managing the damn table, make it so the user doing so has to
>> ask for the new behavior at _RUN TIME_ via the netlink interface
>> or similar.
>>
>> Picking the guard time itself at compile time is also undesirable.
>>
>> And you don't even want a damn timer, what you want is for the
>> state of the entry to be frozen and for the user to "release"
>> it by either adjusting the state to something else or marking
>> in some other way to allow it to be unfrozen and released again.
>>
>> Why put it to chance with some timeout?  Make things explicit.
>>
>> I'm not applying this patch.
:
> Sounds reasonable comments to me.
>
> Would this approach work?
>
> 2 new message types are defined, to enable/disable the garbage
> collection functionality.
>
> RTM_ENANEIGHGC
> RTM_DISANEIGHGC
>
>
> When the functionality is disabled, the stack will not garbage collect,
> and the external application will have to send netlink messages
> to delete unwanted entries.
>
> 1 new message is defined to move an entry from STALE to DELAY.
> RTM_NEIGHRECOVER

Why don't you "explicitly" set the neighbour, or mark the neighbour
entry as PERMANENT via netlink when you recognized that the entry
has become REACHABLE, then?

--yoshfuji