Hello! > Thanks for that explanation - it helps somewhat - one thing I was > confused by was why the timer mechanism for the garbage collection > was so elaborate; why does it do all that back off stuff and > adjusting itself? Why not just run at some fixed rate?
What's about timer in dst.c, it is just saving useless (and large) work. In default configuration you can have ~64K of dst entries listed there without any chances to be released. Remember, those dst entries which are queued in dst.c are _in_use_. Dst entry can be in use for long time only if it is hold by a socket. (Routes used for forwarding are never in use and most of them do not ever reach dst.c. See? This means it is not essential in your case at all) F.e. if a TCP socket holds a route it will not be released until some event on the socket f.e. retransmission. So, if we see some entries not released after short timeout, they are going to stay for long time. Main observation is that it must be totally harmless to hold even unreferenced entries there, provided max_size is set to a reasonable value. F.e. if it is > 2*file_max, nothing bad can happen. Well, Herbert pointed out one situation when it can, but it is really unusual. Alexey - 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
