Date: Tue, 15 Dec 1998 15:55:17 GMT From: Michael Robinson <robinson@netrinsics.com> To: fenner@parc.xerox.com Cc: freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: MLEN < write length < MINCLSIZE "bug" Message-ID: <199812151555.PAA07456@netrinsics.com> In-Reply-To: <199812150552.VAA17801@mango.parc.xerox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bill Fenner <fenner@parc.xerox.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812151555.PAA07456>