From owner-freebsd-net@FreeBSD.ORG Tue Jul 4 20:04:24 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65E5C16A4DA; Tue, 4 Jul 2006 20:04:24 +0000 (UTC) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB13F43D55; Tue, 4 Jul 2006 20:04:23 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id k64JwwY2014536; Tue, 4 Jul 2006 12:58:58 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id k64JwwgK014535; Tue, 4 Jul 2006 12:58:58 -0700 Date: Tue, 4 Jul 2006 12:58:58 -0700 From: Brooks Davis To: Harti Brandt Message-ID: <20060704195858.GB12928@odin.ac.hmc.edu> References: <44A40C25.904@elischer.org> <20060630115749.G3964@fledge.watson.org> <20060703202803.GA22556@odin.ac.hmc.edu> <20060704.102539.-494099438.imp@bsdimp.com> <20060704174208.GA1734@odin.ac.hmc.edu> <20060704195220.K74584@beagle.kn.op.dlr.de> <44AAB986.2070505@elischer.org> <20060704205916.X74584@beagle.kn.op.dlr.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7iMSBzlTiPOCCT2k" Content-Disposition: inline In-Reply-To: <20060704205916.X74584@beagle.kn.op.dlr.de> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new Cc: src-committers@freebsd.org, yar@comp.chem.msu.su, rwatson@freebsd.org, Julian Elischer , freebsd-net@freebsd.org, "M. Warner Losh" Subject: Re: cvs commit: src/sys/net if_vlan.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2006 20:04:24 -0000 --7iMSBzlTiPOCCT2k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 04, 2006 at 09:02:32PM +0200, Harti Brandt wrote: > On Tue, 4 Jul 2006, Julian Elischer wrote: >=20 > JE>Harti Brandt wrote: > JE> > JE>> On Tue, 4 Jul 2006, Brooks Davis wrote: > JE>>=20 > JE>> BD>On Tue, Jul 04, 2006 at 10:25:39AM -0600, M. Warner Losh wrote: > JE>> BD>> In message: <20060703202803.GA22556@odin.ac.hmc.edu> > JE>> BD>> Brooks Davis writes: > JE>> BD>> : and act as though the interface is not there. We could then > JE>> consider > JE>> BD>> : either holding the interface for a configurable or computed l= ength > JE>> BD>> : of time or adding some sort of refcounting (probably impracti= cal). > JE>> BD>> BD>> Refcounting would be good for the 'macro' things (coming a= nd > JE>> going) > JE>> BD>> that are infrequent, but we might have mulitple people doing. = You are > JE>> BD>> right it likely is too inefficient to do with mbugs. One other= option > JE>> BD>> might be to have a configurable time after the last time that i= t was > JE>> BD>> accessed via the 'safe' routines that were setup. This way we'= d tie > JE>> BD>> the removal of the interface to a period of time after it was l= ast > JE>> BD>> used, rather than after it was removed. I don't know if such a > JE>> BD>> difference would matter much in practice. > JE>> BD> > JE>> BD>We might get some mielage out of last used, but then we'd have to= keep > JE>> BD>that timestamp updated. For normal applications, once we've torn= down > JE>> BD>the sockets and drained their queues, I believe we should not hav= e to > JE>> BD>wait more than a few seconds unless dummynet or some other mechan= ism > JE>> BD>that queues mbufs for a significant period of time is enabled. If > JE>> BD>dummynet is enabled we need to wait a bit longer, but it isn't ou= tside > JE>> BD>the relm of possibility for dummynet to be modified to tell us ho= w long > JE>> BD>it will be until the last mbuf it currenly holds will be released= . In > JE>> BD>practice, 121 seconds is probably a good default number since a 60 > JE>> BD>second max RTT is assumed in TCP and thus delays longer than that > JE>> BD>would break everything anyway. > JE>> BD> > JE>> BD>> The only other 'issue' that I see with this approach is if I re= move a > JE>> BD>> card, and then insert it again before the timeout happens. Doe= s that > JE>> BD>> card get a new interface name? And would people care or not... > JE>> BD> > JE>> BD>The name is unregistered with the call to if_detach because if_de= tach > JE>> BD>removes the interface from the ifnet list. My guess is that > JE>> BD>we'll either zero the name field or set to something like _zombie= . The > JE>> BD>unit will remain reserved until later. We'll need to add an SNMP= index > JE>> BD>mananaged in userland to satisfy come current if_index consumers. > JE>>=20 > JE>> bsnmp does this anyway because of the rules for ifIndex. It has some > JE>> heuristic to guess whether an interface is a physical one or not and= if it > JE>> is, it uses the same index again. The downside of this is that the > JE>> interface index you see via SNMP has nothing to do with the interfac= e index > JE>> you see in the system and this does not work accross reboots and dae= mon > JE>> restarts as required by the RFC. > JE> > JE>If we had a way to to this in the system (e.g. kept the mac address=20 > JE>with the ifnum in a hash) then we could just keep the ifnum in the mbu= f=20 > JE>instead of the ifp pointer, as that is only occasionally used, and a= =20 > JE>ifnum2ipf() macro could check the validity wheheve it is used. >=20 > This would be helpful for the SNMP daemon, because this would also allow= =20 > to reuse the ifnum if the same interface is plugged in back. However care= =20 > must be taken that non-physical interfaces get a new ifnum always (iftun= =20 > for example). This belongs in userland. It's too complex to handle in the kernel. We probably need to store the index in the kernel as a rondivues point, but the actual decision on deciding which interfaces are the "same" and which are "different" as defined by the SNMP spec is too difficult and has too many edge cases to try to do in the kernel. I think the right answer is a daemon (or devd triggered script) that sets the SNMP index based on a database containing previous lladdrs and units. -- 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 --7iMSBzlTiPOCCT2k Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFEqsiBXY6L6fI4GtQRAk6qAJ9pN6W16KR9Pn9vZfCos4uMweOeRACeNkhz iuOO3BASLA9qW+rBxnNQKu0= =eu1T -----END PGP SIGNATURE----- --7iMSBzlTiPOCCT2k--