Date: Wed, 05 Mar 1997 22:36:18 -0800 From: Julian Elischer <julian@whistle.com> To: Hackers@freebsd.org Subject: Network gurus? in_rmx.c.. why? Message-ID: <331E65E2.41C67EA6@whistle.com>
next in thread | raw e-mail | index | archive | help
As those of you who've been following things probably know.. We at Whistle have a need for things such as interfaces to come and go, and for routes to be cleanly destroyed when we reassingn addresses here and there in a dynamic manner. The answer "reboot the machine" may make the problems go away, but we'd rather not have the customer calling customer service in the first place.. For this reason I've been going through the networking (read routing) code and have been compiling a set of changes that clear up some of the absolute confusion presently in the routing code (it's a mess for hysterical raisons I guess). All was progressing fine until this evenning, when I got as far as in_rmx.c. In one fell swoop, all the work I'd done to make all the reference counting in the routing code be consistent and rigourously applied, came to a stop. This module actually relies on the reference counts for rtentry structs to be incorrect. i.e. it assumes (and needs to assume) that only references generated by rtalloc1() are counted.. In other words rt_refcnt is only a count of references by open sessions. The trouble is that to really be able to clean up the routing code properly, we actually need a REAL reference count. At least this is my belief. I invite opposing viewpoints. My suggestion for this would be to impliment a second reference counter. so there would be two. 1/ a count of all real references. 2/ a count of 'session' (PCB) references. there are a few ways to actually achieve this effect: 1/ rtalloc1() uses one and everything else uses another. this requires 2 version s of rtfree() and the total references is the sum of the two. 2/ rtalloc increments both, and everything else just increments the real one. 3/ whenever the 'users' is non 0, 1 is added to the reference count. (sort of daisy chaining them). 4/ have everything access one reference counters and have non PCB users also access a second.. subtracting 2 from 1 gives the number of sessions. Am I right in thinking that the only reason in_rmx needs to know when a route is not in use is so that it can keep the number of kernel routes in a place like wcarchive under control? In other words.. it's to know when it can safely delete a route. ? Couldn't it just be assumed that inactivity on a host route over some period of time would constitute enough reason in itself if it was not a static route? The reason to not delete the route too quickly would be what? to hold useful info about the path to that system? does TTCP make use of that? does anyone think that getting the reference counts under stricter control is a stupid idea? I get the impression that this may be the thought in some quarters.. julian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?331E65E2.41C67EA6>