Date: Tue, 4 Jul 2006 10:42:08 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: "M. Warner Losh" <imp@bsdimp.com> Cc: src-committers@FreeBSD.org, yar@comp.chem.msu.su, rwatson@FreeBSD.org, julian@elischer.org, freebsd-net@FreeBSD.org Subject: Re: cvs commit: src/sys/net if_vlan.c Message-ID: <20060704174208.GA1734@odin.ac.hmc.edu> In-Reply-To: <20060704.102539.-494099438.imp@bsdimp.com> References: <44A40C25.904@elischer.org> <20060630115749.G3964@fledge.watson.org> <20060703202803.GA22556@odin.ac.hmc.edu> <20060704.102539.-494099438.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 04, 2006 at 10:25:39AM -0600, M. Warner Losh wrote: > In message: <20060703202803.GA22556@odin.ac.hmc.edu> > Brooks Davis <brooks@one-eyed-alien.net> writes: > : and act as though the interface is not there. We could then consider > : either holding the interface for a configurable or computed length > : of time or adding some sort of refcounting (probably impractical). >=20 > Refcounting would be good for the 'macro' things (coming and going) > that are infrequent, but we might have mulitple people doing. You are > right it likely is too inefficient to do with mbugs. One other option > might be to have a configurable time after the last time that it was > accessed via the 'safe' routines that were setup. This way we'd tie > the removal of the interface to a period of time after it was last > used, rather than after it was removed. I don't know if such a > difference would matter much in practice. We might get some mielage out of last used, but then we'd have to keep that timestamp updated. For normal applications, once we've torn down the sockets and drained their queues, I believe we should not have to wait more than a few seconds unless dummynet or some other mechanism that queues mbufs for a significant period of time is enabled. If dummynet is enabled we need to wait a bit longer, but it isn't outside the relm of possibility for dummynet to be modified to tell us how long it will be until the last mbuf it currenly holds will be released. In practice, 121 seconds is probably a good default number since a 60 second max RTT is assumed in TCP and thus delays longer than that would break everything anyway. > The only other 'issue' that I see with this approach is if I remove a > card, and then insert it again before the timeout happens. Does that > card get a new interface name? And would people care or not... The name is unregistered with the call to if_detach because if_detach removes the interface from the ifnet list. My guess is that we'll either zero the name field or set to something like _zombie. The unit will remain reserved until later. We'll need to add an SNMP index mananaged in userland to satisfy come current if_index consumers. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --jI8keyz6grp/JLjh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFEqqhvXY6L6fI4GtQRAgIJAKCLB1mGVIkKv5nYRED+Dsi33GN9aACeNX9n T4KL4DTb2qW9GJkei79pykM= =4sP+ -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060704174208.GA1734>