Re: [RESEND] [NET] fib_rules: Flush route cache after rule modifications

[Jarek Poplawski <jarkao2@o2.pl>]

On Wed, Mar 28, 2007 at 09:34:36PM +0200, Thomas Graf wrote:
> * David Miller <davem@davemloft.net> 2007-03-28 11:24
> > Another idea Thomas and I tossed around was to have some kind of way
> > for the rule insertion to indicate that the flush should be deferred
> > and I kind of prefer that explicitness.
> 
> Right, although I believe the flag should not only defer it
> but not flush at all. This would be the optimal solution
> for scripts which can do a ip ro flush cache as they know
> what they're doing.
> 
> > By default it's better the flush immediately, because the old
> > behavior is totally unexpected.  "I insert a rule and it dosn't
> > show up?", nobody expects that.
> 
> It's a tough call, I'd favour immediate flush as well but I can
> see the point in delaying by ip_rt_min_delay which can be
> configured by the user. So people can choose to immediately flush
> by setting it to 0. It would also be consistent to the flush
> after route changes, the same delay is used there.
> 

Of course you both are right - but (...I've some doubts):

- there is a difference between tools: route or ip route
(as a successor) and ip rule; the latter is intended for
advanced things, so users have to expect... (or RTFM!).
 
- of course immediate flush seems to be more natural, but
it isn't like that and rules (other rules) are changed,
so maybe some transitory way is needed; these 2s look
like a good compromise, but after looking into
rt_cache_flush - it's not for all (I know - we don't like
multipath - but untill it's here...) and these locks and
timers aren't for free, too; so, IMHO, something like
-n[oflush] option is a mustbe.

- for consistency probably all ip "objects" should be
verified: "to flush or not to flush" by default.

Cheers,
Jarek P.