cvs commit: src/sys/net rtsock.c

[Brooks Davis]

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.

-- Brooks

-- 
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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20040823/15980f32/attachment.bin