From owner-cvs-src@FreeBSD.ORG Tue Oct 19 23:29:19 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C34C16A4CE; Tue, 19 Oct 2004 23:29:19 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 521D743D1D; Tue, 19 Oct 2004 23:29:19 +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 i9JNU3gH014696; Tue, 19 Oct 2004 16:30:03 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i9JNU33x014695; Tue, 19 Oct 2004 16:30:03 -0700 Date: Tue, 19 Oct 2004 16:30:03 -0700 From: Brooks Davis To: Julian Elischer Message-ID: <20041019233003.GA11960@odin.ac.hmc.edu> References: <41759110.6010005@elischer.org> <20041019223754.GA16741@odin.ac.hmc.edu> <41759F5B.9080502@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline In-Reply-To: <41759F5B.9080502@elischer.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: src-committers@FreeBSD.org cc: Andre Oppermann cc: Brooks Davis cc: cvs-src@FreeBSD.org cc: cvs-all@FreeBSD.org cc: Robert Watson cc: Max Laier cc: Sam Leffler Subject: Re: cvs commit: src/sys/sys protosw.h src/sys/kern uipc_domain.cuipc_socket2.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 23:29:19 -0000 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 19, 2004 at 04:12:27PM -0700, Julian Elischer wrote: >=20 >=20 > Brooks Davis wrote: >=20 > >On Tue, Oct 19, 2004 at 06:19:10PM -0400, Robert Watson wrote: > >=20 > > > >>On Tue, 19 Oct 2004, Julian Elischer wrote: > >> > >> =20 > >> > >>>>>Another point: If you really want to keep the possibility to remove a > >>>>>protocol, you have to introduce some busy counter that pervents=20 > >>>>>removal while > >>>>>the kernel is inside a protocol function. This has to be handled by = the > >>>>>protocol itself, but it has to be taken care of somehow. > >>>>> =20 > >>>>> > >>>each protocol array entry could have either a mutex or a refcount or > >>>both..=20 > >>> =20 > >>> > >>The trick here is to get just enough synchronization to not break, but = not > >>enough to hurt. That's one of the reasons why I feel like the heavier > >>weight approaches taken elsewhere may not be appropriate here. I guess= no > >>one is talking about loading UDP, but at the same time if we're going to > >>have generic loadable protocol support, it would be nice to get a pretty > >>clean API that would meet the requirements of higher volume protocols. = As > >>I mentioned in a previous e-mail, it might almost be desirable to say "= no > >>unloading" and simply avoid the hard problems, since atomic add is easy > >>whereas atomic remove is hard. > >> =20 > >> > > > >One of the things I've been looking at with interfaces is trying to > >squash the really big races (mostly dummynet) by avoiding holding a > >pointer to an interface any longer then necessicary. Instead I'm > >=20 > > > >planning to hold interface indexes instead. =20 > >=20 > > > I've been against this idea for some time.. > there are some situations where interfaces can get created and destroyed= =20 > as some relatively large rate. > (i.e several per second in a worst case.) >=20 > In particular I've seen interface reation and deltion on a very dynamic= =20 > manner with some > proprietary VPN solutions with interfaces coming and going on a regular= =20 > basis as links come up and down. >=20 >=20 > Consider doing the same as we do for PIDS.. > in 386bsd. one of the ealiest bugs we saw was traced back originally to= =20 > something using a process > pointer which had been stored somewhere. (The process however could exit) > The fix was to make a hash-table of pids and store the pid instead, (and= =20 > a gen number). > If the process went away you couldn't find it, and the gen number would= =20 > stop you from matching new processes. >=20 > I think the same thing here.. rather than storing an index into an array= =20 > (which could change or > become invalid.) store a long interface ID that is always incremented=20 > and kept in a > small hash table. This allows the slots in the array to be reused. =20 > (It's a pity an index is required by > some standards.. maye however they could live with the ID as well). > I'll live with the wrap time for interface creation.. (It'll probably=20 > outlive me however..) We now have the index plus generation number in the form of if_data.ifi_epoch so you can do that trick (if interfaces are being created and destroyed with sub-second frequency we can move to storing a bintime from a time_t in the 6.x timeframe.) The indexes we generate are useless for SNMP in vpn-like environments. I've proposed a couple of partial solutions in my EuroBSDCon paper, but at the end of the day, complex systems like VPN concentrators will need to manage their own indexes entirely internally and only use the if_index as a temporary handle on each interface. -- 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 --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBdaN6XY6L6fI4GtQRAiwJAJ0WR6R3dS1Qrugyda/CWLGaRKw/3QCgtH8B dSnuIMaYEnsNALmTm72q18k= =Guno -----END PGP SIGNATURE----- --ibTvN161/egqYuK8--