cvs commit: src/sys/net rtsock.c
rwatson at freebsd.org
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 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 at fledge.watson.org Principal Research Scientist, McAfee Research
More information about the cvs-all