On Wed, Mar 28, 2007 at 09:34:36PM +0200, Thomas Graf wrote: > * David Miller <[EMAIL PROTECTED]> 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. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
