cvs commit: src/sys/net rtsock.c
Brooks Davis
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.
-- 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-all/attachments/20040823/15980f32/attachment.bin
More information about the cvs-all
mailing list