From owner-freebsd-stable Mon Dec 14 20:40:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA08264 for freebsd-stable-outgoing; Mon, 14 Dec 1998 20:40:39 -0800 (PST) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from dingo.cdrom.com (goldfish.pht.co.jp [210.171.55.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA08238 for ; Mon, 14 Dec 1998 20:40:29 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id UAA02728; Mon, 14 Dec 1998 20:37:05 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199812150437.UAA02728@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Michael Robinson cc: mike@smith.net.au, freebsd-stable@FreeBSD.ORG Subject: Re: MLEN < write length < MINCLSIZE "bug" In-reply-to: Your message of "Tue, 15 Dec 1998 12:27:57 GMT." <199812151227.MAA06983@netrinsics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Dec 1998 20:36:54 -0800 From: Mike Smith 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. I'd really prefer diffs against -current; that's where this would be committed. > >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: ... > For these reasons, I think a socket option makes more sense than trying to > resolve the problem automagically in the kernel. That makes sense. > 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. That's *definitely* a better idea, and not much harder than the sysctl. Again, diffs against -current would be good, but anything'd be a start... -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message