Date: Thu, 25 Mar 1999 18:29:14 -0800 (PST) From: Jim Shankland <jas@flyingfox.com> To: kml@nas.nasa.gov Cc: freebsd-net@freebsd.org Subject: Re: mbuf clusters and socket send buffers (was Re: 3.1-STABLE dies on 40+ connects) Message-ID: <199903260229.SAA22400@biggusdiskus.flyingfox.com> In-Reply-To: <199903260051.QAA17517@gecko.nas.nasa.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
"Kevin M. Lahey" <kml@nas.nasa.gov> writes: > In message <199903260054.QAA22060@biggusdiskus.flyingfox.com>, > Jim Shankland writes: > >A thought related to this discussion: does it make sense to allow the > >send buffers to be larger than the peer's advertised window size? > >In other words, why "preposition" those bytes in the kernel before > >the peer has indicated a willingness to accept them? > > Interestingly enough, no memory is actually used until data arrives. > The socket buffer size is merely a cap on the amount of memory that > could possibly be allocated for that connection. I'm not sure whether you misunderstood my point, or were just making a related observation. Just in case, let me clarify with a concrete example: A program sets its socket send buffer size to 64KB. At some instant, the kernel has 8KB of data in its send buffer, which is exactly how much the receiving end has indicated (via the window advertisement) it is willing to accept. The sending process issues another 8 KB write() call. Should the kernel accept the 8 KB of data, allocating more mbufs and returning from the write(), or should it stall the write() call until the receiving end grows the window? Making this change would not fix the crash-when-you-run-out-of-mbufs problem, but would make it a bit less frequent, and would conserve kernel memory. It's just a thought, but I thought I'd run it up the flagpole .... Jim Shankland NLynx Systems, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903260229.SAA22400>