From owner-freebsd-net Tue Dec 15 03:46:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA16445 for freebsd-net-outgoing; Tue, 15 Dec 1998 03:46:40 -0800 (PST) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from netrinsics.com ([210.74.178.16]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA16427; Tue, 15 Dec 1998 03:46:31 -0800 (PST) (envelope-from robinson@netrinsics.com) Received: (from robinson@localhost) by netrinsics.com (8.8.8/8.8.7) id PAA07456; Tue, 15 Dec 1998 15:55:17 GMT (envelope-from robinson) Date: Tue, 15 Dec 1998 15:55:17 GMT From: Michael Robinson Message-Id: <199812151555.PAA07456@netrinsics.com> To: fenner@parc.xerox.com Subject: Re: MLEN < write length < MINCLSIZE "bug" Cc: freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG In-Reply-To: <199812150552.VAA17801@mango.parc.xerox.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bill Fenner writes: >You misunderstand. The fix is to accumulate mbufs in a chain until either >a) The protocol gets all of the data that it wanted, or >b) All of the data that the user has provided has been copied into mbufs. > >(b) is what sosend() used to do. The URL referenced (the one with >"vanj88" in it) describes why sosend() was changed to use only a single >mbuf at a time, but this performance problem was not envisioned at >the time. Ok, I misunderstood. But I still disagree it's a bug. Or, more precisely, it would be a bug if the socket API and the TCP protocol were seen as one inseparable entity, which is not the case. There does not seem to me to be anything inherently broken at the socket abstraction layer with the practice of writing one "write" out to a streaming protocol in multiple packets. Nor does there seem to be anything inherently broken at the TCP abstraction layer with buffering streamed input until an ACK is received. Together, these performance optimizations at different levels of abstraction can interact badly, under a particular set of circumstances, but is that really a bug, per se? Having read the Van Jacobson argument for parallelism, though, I have to wonder how that relates to the current implementation of sosend in FreeBSD. It seems that we only get the "parallelism" if the write length is more than one mbuf and less than two. A write of two mbufs plus one byte is copied into a cluster, which gives you all the non-parallelism of the original "chain mbufs" solution, and all the memory inefficiency of cluster allocation. Is there any documentation on why MINCLSIZE is currently set to the value it is? -Michael Robinson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message