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

From: Ulf Samuelsson <[email-masked]>
Date: Wed, 18 Mar 2015 00:33:56 +0100

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.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [email-masked]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
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

Will have to discuss internally to see if this works.

BR
Ulf Samuelsson