From owner-freebsd-stable Mon Dec 14 20:34:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA07406 for freebsd-stable-outgoing; Mon, 14 Dec 1998 20:34:16 -0800 (PST) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from netrinsics.com ([210.74.176.100]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA07401 for ; Mon, 14 Dec 1998 20:34:06 -0800 (PST) (envelope-from robinson@netrinsics.com) Received: (from robinson@localhost) by netrinsics.com (8.8.8/8.8.7) id MAA06983; Tue, 15 Dec 1998 12:27:57 GMT (envelope-from robinson) Date: Tue, 15 Dec 1998 12:27:57 GMT From: Michael Robinson Message-Id: <199812151227.MAA06983@netrinsics.com> To: mike@smith.net.au, robinson@netrinsics.com Subject: Re: MLEN < write length < MINCLSIZE "bug" Cc: freebsd-stable@FreeBSD.ORG In-Reply-To: <199812150247.SAA02006@dingo.cdrom.com> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith writes: >> 4. One solution is to make MINCLSIZE a kernel config option. This is ugly, >> but simple to implement and relatively non-intrusive. > >It should be a sysctl variable, not a kernel option, in this case. But >that's certainly the simplest way to go. Want to implement this? Will do. Will patches against the 2.2.7-RELEASE CVS repository be acceptable? If there hasn't been too much drift, they should easily merge into -STABLE, and maybe even -CURRENT. >> With a socket option, applications that wanted low latency (at the >> expense of more memory usage) could specify that on a per-socket basis. >> This is less ugly, but requires extensive changes to documentation, >> header files, and application software. > >Do you think you could come up with a heuristic that would be able to >detect when the current behaviour was losing, reliably? If so, you >could use this to switch the option... By adding one or two bookkeeping fields to the socket structure it would be possible to implement such an heuristic. However, there are three reasons I don't think that is such a good idea: 1. Protocol inefficiencies from sending multiple packets are, by their nature, protocol dependent. Ergo, we would want different heuristics for different families (LOCAL, INET, ISO, etc.) and types (STREAM, DGRAM, etc.) of socket. Which gets really ugly really fast. 2. There is no method to determine how much any given application cares about protocol inefficiencies on any given socket. The heuristic would be making perhaps unwarranted assumptions about what performance characteristics were desireable in a particular instance. Which is how we got into this mess in the first place. 3. It would be non-trivial extra code in a pretty performance-sensitive part of the kernel (the innermost loop of sosend). For these reasons, I think a socket option makes more sense than trying to resolve the problem automagically in the kernel. Perhaps a more tractable solution would be a system-wide heuristic, such as is used with filesystem tuning. I.e., if there are mbuf clusters to burn, burn 'em, baby. Otherwise, send multiple packets. -Michael Robinson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message