cvs commit: src/sys/net rtsock.c

Robert Watson rwatson at
Sun Aug 22 07:53:21 PDT 2004

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>
> 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 at      Principal Research Scientist, McAfee Research

More information about the cvs-all mailing list