From owner-freebsd-net@FreeBSD.ORG Tue Jul 4 19:51:43 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 999FE16A4DD; Tue, 4 Jul 2006 19:51:43 +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 3499543D46; Tue, 4 Jul 2006 19:51:43 +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 k64JkIJl013761; Tue, 4 Jul 2006 12:46:18 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id k64JkIQE013760; Tue, 4 Jul 2006 12:46:18 -0700 Date: Tue, 4 Jul 2006 12:46:18 -0700 From: Brooks Davis To: Julian Elischer Message-ID: <20060704194618.GA12928@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> <44AAB7D5.5010609@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <44AAB7D5.5010609@elischer.org> 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, 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 19:51:43 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 04, 2006 at 11:47:49AM -0700, Julian Elischer wrote: > M. Warner Losh wrote: >=20 > >In message: <20060703202803.GA22556@odin.ac.hmc.edu> > > Brooks Davis 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). > > > >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. > > > >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... >=20 > As I mentionned earlier, the mbuf references are not always used. They > are mainly used for ipfw and friends but are not always used (from > memory) on every packet in the receive path. > > In this case it may be as well to have an indirect reference tha can > be checked for validity each time.. e.g. ifnum. it wouldn't be too > much to keep the ifnum slots around for a period after the interfaces > are destroyed. (and marked invalid), or in tha case of a hash, failure > to find it would suggest that is is invalid. As long as the index was once valid, you can check it's existance with (ifnet_byindex() !=3D NULL), but you can't know if if what's there is actually the interface you were looking for unless you also cache and check if_data.if_epoch. Changes to doing more references to interfaces by index are a good idea where they don't have a performance impact, but we need to be careful with overhead since we add a level of indirection with particular care to test the case where we have large numbers of interfaces and thus the array used by ifnet_byindex is large and will have cache effects. It's worth remembering that an ifnet isn't very expensive (and we could make them cheaper still with their own zone) so if keeping them valid a bit instead of checking for validity has a measurable performace impact in the common case we should do it. -- 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 --FCuugMFkClbJLl1L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFEqsWJXY6L6fI4GtQRAq81AKCJ+jR6dDrwYN/8WxsueUuTtD2QXgCgrHdc TWHumZ2I4MHxg3ZzY0Q3bZE= =FCpq -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L--