Date: Mon, 23 Aug 2004 11:05:19 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: Robert Watson <rwatson@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/net rtsock.c Message-ID: <20040823180519.GC21483@odin.ac.hmc.edu> In-Reply-To: <Pine.NEB.3.96L.1040822103602.5376G-100000@fledge.watson.org> References: <4128673E.F68B68EE@freebsd.org> <Pine.NEB.3.96L.1040822103602.5376G-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Md/poaVZ8hnGTzuv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 22, 2004 at 10:51:13AM -0400, Robert Watson wrote: >=20 > On Sun, 22 Aug 2004, Andre Oppermann wrote: >=20 > > > Allow the size of the routing socket netisr queue to be configured = using > > > the tunable or sysctl 'net.route.netisr_maxqlen'. Default the maxi= mum > > > depth to 256 rather than IFQ_MAXLEN due to the downsides of dropping > > > routing messages. > > >=20 > > > MT5 candidate. > > >=20 > > > Discussed with: mdodd, mlaier, Vincent Jardin <jardin at 6wind.com> > >=20 > > A rtmessage should never ever be dropped. That would wedge the > > synchronized state of any userland routing daemons.=20 >=20 > That as may be, but we've always been able to drop them when the routing > socket socket buffers fill, or when are unable to allocate an mbuf due to > low memory, as we're often unable to block when such a message is > generated. Inserting a netisr dispatch inserted a new bounded length > queue introduced another possible source of loss when the queue overflows. > I chatted with Bruce Simpson about this, and he observed that the way > routing daemons may/do address some of the potential loss is to set the > socket buffer receive size higher; this is not fail safe, however. I > asked the submitter of the issue what the highest watermark level for > socket buffers we'd seen in practice was, but I have not seen a response > to that. He suggested making the netisr queue depth for the routing > socket to be unlimited; I made it configurable but set what I think is a > fairly high default. Do you have any measurement of how deep that socket > buffer gets in practice on high volume routers?=20 It might be useful to add a RTM_FOOBAR (or similar :-) message to send when we are forced to drop a message. It's impossiable to be 100% certain we will never drop a message so having a mechanism to indicate that things have gone wrong could be useful. -- 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 --Md/poaVZ8hnGTzuv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBKjHeXY6L6fI4GtQRAsO7AJ9sm1DsQc8QnTmA3puzBz5aXAYZpQCeJOBe +oICw6nL0ldaIsxlTPzj5ic= =mKij -----END PGP SIGNATURE----- --Md/poaVZ8hnGTzuv--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040823180519.GC21483>