From owner-cvs-all@FreeBSD.ORG Sun Aug 22 14:53:21 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1145816A4CE; Sun, 22 Aug 2004 14:53:21 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABA1643D1F; Sun, 22 Aug 2004 14:53:20 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7MEpD00020079; Sun, 22 Aug 2004 10:51:13 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7MEpDDw020076; Sun, 22 Aug 2004 10:51:13 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 22 Aug 2004 10:51:13 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Andre Oppermann In-Reply-To: <4128673E.F68B68EE@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/net rtsock.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2004 14:53:21 -0000 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 > > 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