Date: Tue, 20 Mar 2007 16:20:25 +0300 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Bruce M Simpson <bms@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet raw_ip.c Message-ID: <20070320132025.GP2713@FreeBSD.org> In-Reply-To: <200703201315.l2KDFKd0065099@repoman.freebsd.org> References: <200703201315.l2KDFKd0065099@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 20, 2007 at 01:15:20PM +0000, Bruce M Simpson wrote: B> bms 2007-03-20 13:15:20 UTC B> B> FreeBSD src repository B> B> Modified files: B> sys/netinet raw_ip.c B> Log: B> Increase default size of raw IP send and receive buffers to the same as B> udp_sendspace, to avoid a situation where jumbograms (datagrams > 9KB) B> are unnecessarily fragmented. B> B> A common use case for this is OSPF link-state database synchronization B> during adjacency bringup on a high speed network with a large MTU. B> B> It is not possible to auto-tune this setting until a socket is bound to B> a given interface, and because the laddr part of the inpcb tuple may be B> overridden, it makes no sense to do so. Applications may request a larger B> socket buffer size by using the SO_SENDBUF and SO_RECVBUF socket options. B> B> Certain applications such as Quagga ospfd do not probe for interface MTU B> and therefore do not increase SO_SENDBUF in this use case. B> XORP is not affected by this problem as it preemptively uses SO_SENDBUF B> and SO_RECVBUF to account for any possible additional latency in XRL IPC. B> -u_long rip_sendspace = RIPSNDQ; B> -u_long rip_recvspace = RIPRCVQ; B> +u_long rip_sendspace = 9216; B> +u_long rip_recvspace = 9216; We've got interfaces with even larger MTU. Why shouldn't we permit sending larger datagrams? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070320132025.GP2713>