cvs commit: src/sys/net rtsock.c
brooks at one-eyed-alien.net
Mon Aug 23 11:04:02 PDT 2004
On Sun, Aug 22, 2004 at 10:51:13AM -0400, Robert Watson wrote:
> 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?
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.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20040823/15980f32/attachment.bin
More information about the cvs-src