Date: Sun, 22 Aug 2004 10:51:13 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Andre Oppermann <andre@freebsd.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/net rtsock.c Message-ID: <Pine.NEB.3.96L.1040822103602.5376G-100000@fledge.watson.org> In-Reply-To: <4128673E.F68B68EE@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 22 Aug 2004, Andre Oppermann wrote: > > Allow the size of the routing socket netisr queue to be configured using > > the tunable or sysctl 'net.route.netisr_maxqlen'. Default the maximum > > depth to 256 rather than IFQ_MAXLEN due to the downsides of dropping > > routing messages. > > > > MT5 candidate. > > > > Discussed with: mdodd, mlaier, Vincent Jardin <jardin at 6wind.com> > > A rtmessage should never ever be dropped. That would wedge the > synchronized state of any userland routing daemons. 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? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040822103602.5376G-100000>