Date: Tue, 13 Aug 2002 02:13:33 -0700 From: Luigi Rizzo <rizzo@icir.org> To: Ruslan Ermilov <ru@FreeBSD.org> Cc: net@FreeBSD.org Subject: Consistency of cached routes Message-ID: <20020813021333.A4507@iguana.icir.org> In-Reply-To: <20020813085122.GC54451@sunbay.com>; from ru@FreeBSD.org on Tue, Aug 13, 2002 at 11:51:22AM %2B0300 References: <200208091449.g79EnNRh005472@freefall.freebsd.org> <20020809080953.B62786@iguana.icir.org> <20020811105249.GB11677@sunbay.com> <20020811054337.B84502@iguana.icir.org> <20020812123953.GB41233@sunbay.com> <20020812145105.B148@iguana.icir.org> <20020813085122.GC54451@sunbay.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[moved to -net because more relevant there] Summary of previous discussion: ip_forward, ipflow and TCP/UDP sockets cache a copy of the result of route lookups, but these entries might be out-of-date when a routing update is performed. Ruslan just MFC'ed a fix to invalidate the (one-entry) cache in ip_forward, but the other two can still be inconsistent. On Tue, Aug 13, 2002 at 11:51:22AM +0300, Ruslan Ermilov wrote: ... > > so, I have a question here... i believe TCP sockets cache a > > host route to the destination (say 10.0.0.1 in your example), > > possibly cloning one from a more generic one (e.g. 10/8). > > Now how does the invalidation works if someone adds say > > a different 10.0.0/24 route ? The 10/8 is still alive... > > > Yes, this is a known bug, and that is why PR kern/10778 is still > open. ok, so i guess it is time to instrument route lookups and see how expensive they are, and sort out what is the best way to solve the tradeoff between caching and potential inconsistencies. The timestamp idea is good because it has constant cost, though on a box with many routing updates it might completely defeat the cache. The second thing you propose has less impact on the cache, but has potentially a very high cost when doing the route update. Ideas anyone ? This might be a problem with a known efficient solution. cheers luigi > The idea was to add the timestamping facility to the routing table > and for the cache entries. Whenever a new route is added to the > routing table, the routing table's timestamp would get updated, > and all cache entries that were cached earlier would then be pruned > on the first access. > > I then gave up on this idea since I had a somewhat better one: when > a new route is added to the routing table, mark all less-specific > entries with refcnt > 0 as "potentially outdate", and perform the > lazy pruning of cache entries as before. > > What you proposed (to use ipflow hash for IP forwarding) would just > re-introduce this bug there. > > > Cheers, > -- > Ruslan Ermilov Sysadmin and DBA, > ru@sunbay.com Sunbay Software AG, > ru@FreeBSD.org FreeBSD committer, > +380.652.512.251 Simferopol, Ukraine > > http://www.FreeBSD.org The Power To Serve > http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020813021333.A4507>