From owner-freebsd-net Mon Dec 14 21:44:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA14500 for freebsd-net-outgoing; Mon, 14 Dec 1998 21:44:22 -0800 (PST) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from netrinsics.com ([210.74.175.236]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA14479; Mon, 14 Dec 1998 21:44:12 -0800 (PST) (envelope-from robinson@netrinsics.com) Received: (from robinson@localhost) by netrinsics.com (8.8.8/8.8.7) id NAA07127; Tue, 15 Dec 1998 13:40:42 GMT (envelope-from robinson) Date: Tue, 15 Dec 1998 13:40:42 GMT From: Michael Robinson Message-Id: <199812151340.NAA07127@netrinsics.com> To: fenner@parc.xerox.com, robinson@netrinsics.com Subject: Re: MLEN < write length < MINCLSIZE "bug" Cc: freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG In-Reply-To: <98Dec14.205241pst.177534@crevenia.parc.xerox.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bill Fenner writes: >In message <199812141437.OAA00472@netrinsics.com> you write: >> 1. This isn't a bug. It's a performance tradeoff of memory efficiency >> (allocating an mbuf cluster) versus protocol efficiency (sending >> two packets). > >I still think it's a bug; that's why I wrote the (buggy) patch referred >to in the Squid FAQ. See my discussion at >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/uipc_socket.c#rev1.41 >(and in particular, the paragraph labelled "The real fix"...) Well, I've explained the problem, and given a fix (reduce MINCLSIZE to MHLEN+1). You can try my fix, and if it causes any problems for you (other than causing your Squid server to run out of mbuf clusters), then I'll go back to the drawing board. Your "real fix" (accumulate an mbuf chain until it exceeded the "requested transfer size") seems unlikely to fix the problem for Squid and IIOP, because the problem is that writes which are bigger than one mbuf, but smaller than two, don't get sent atomically and immediately (causing protocol latency). Your discussion overlooks the fact that these are client-server protocols that are going to write a request on a socket and then wait for a response. "Accumulating mbufs" until they exceed the TCP MSS is a recipe for deadlock. In such a situation, the only acceptable "requested transfer size" is the length of the write itself, and my fix implements that. -Michael Robinson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message