From owner-cvs-all@FreeBSD.ORG Sat Mar 29 01:20:35 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C22A837B401; Sat, 29 Mar 2003 01:20:35 -0800 (PST) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id CC8C243FA3; Sat, 29 Mar 2003 01:20:33 -0800 (PST) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 29 Mar 2003 09:20:33 +0000 (GMT) Date: Sat, 29 Mar 2003 09:20:29 +0000 From: David Malone To: Luigi Rizzo Message-ID: <20030329092029.GA21929@walton.maths.tcd.ie> References: <200303260452.h2Q4quap015364@www.ambrisko.com> <20030326114030.U2075@odysseus.silby.com> <20030326183351.GJ57674@elvis.mu.org> <20030326130903.G2075@odysseus.silby.com> <20030327013224.P7674@odysseus.silby.com> <031301c2f49b$09d2bfb0$52557f42@errno.com> <20030327153352.A66323@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030327153352.A66323@xorpc.icir.org> User-Agent: Mutt/1.5.3i Sender: dwmalone@maths.tcd.ie cc: src-committers@FreeBSD.org cc: Doug Ambrisko cc: cvs-src@FreeBSD.org cc: Maxime Henrion cc: Sam Leffler cc: Mike Silbersack cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/conf options src/sys/netinet ip_output.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2003 09:20:37 -0000 On Thu, Mar 27, 2003 at 03:33:52PM -0800, Luigi Rizzo wrote: > so individual writes of 513+ bytes will result in wasting up to 75% > of the socket buffer space. At the very least, i would drop the > 'm->m_len <= MCLBYTES / 4' check to reduce the waste. I think I added that test when we were making sbcompress work on data in clusters. There was no profound reason for it, other than preventing it copying complete clusters, which seems rather wasteful. OTOH, if the data is likely to be copied later I guess we may as well compress it more aggressively earlier. (The reason we looked at optimising this was because we were recieveing small packets from a remote X server and the fxp drivers were passing them up in clusters, wasting loads of space in netscape's socketbufs. In our case, the data was much smaller than MCLBYTES/4, so copying any small amount of data was a big win.) David.