From owner-freebsd-net Thu Mar 25 17:18:16 1999 Delivered-To: freebsd-net@freebsd.org Received: from biggusdiskus.flyingfox.com (parker-T1-2-gw.sf3d.best.net [209.157.165.30]) by hub.freebsd.org (Postfix) with ESMTP id 4D1D214ED9 for ; Thu, 25 Mar 1999 17:18:07 -0800 (PST) (envelope-from jas@flyingfox.com) Received: (from jas@localhost) by biggusdiskus.flyingfox.com (8.8.8/8.8.5) id SAA22400; Thu, 25 Mar 1999 18:29:14 -0800 (PST) Date: Thu, 25 Mar 1999 18:29:14 -0800 (PST) From: Jim Shankland Message-Id: <199903260229.SAA22400@biggusdiskus.flyingfox.com> To: kml@nas.nasa.gov Subject: Re: mbuf clusters and socket send buffers (was Re: 3.1-STABLE dies on 40+ connects) Cc: freebsd-net@freebsd.org In-Reply-To: <199903260051.QAA17517@gecko.nas.nasa.gov> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Kevin M. Lahey" 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