From owner-cvs-src@FreeBSD.ORG Thu Mar 27 19:16:25 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D889837B408 for ; Thu, 27 Mar 2003 19:16:25 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 787ED43FBF for ; Thu, 27 Mar 2003 19:16:23 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 4363 invoked from network); 28 Mar 2003 03:16:22 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 28 Mar 2003 03:16:22 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 27 Mar 2003 21:12:57 -0600 (CST) From: Mike Silbersack To: Sam Leffler In-Reply-To: <03d001c2f4b2$ecf461b0$52557f42@errno.com> Message-ID: <20030327211045.D601@odysseus.silby.com> References: <200303260452.h2Q4quap015364@www.ambrisko.com> <20030326183351.GJ57674@elvis.mu.org> <20030327013224.P7674@odysseus.silby.com> <20030327161237.T748@odysseus.silby.com> <03d001c2f4b2$ecf461b0$52557f42@errno.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-25.4 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: Maxime Henrion cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: Doug Ambrisko cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/conf options src/sys/netinet ip_output.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2003 03:16:27 -0000 On Thu, 27 Mar 2003, Sam Leffler wrote: > As I've said already, in the drivers you want to use the minimum-cost > technique to get the packet on the wire. I think your original > single-cluster version is close to what I would do, but so long as this > stuff only happens as an exception to the normal processing path I really > don't care. Just keep stats so we can see how much it's happening. > > Sam Yes, m_defrag will only be used in exceptional cases, where defragmentation is necessary or highly desireable. I have one statistic in there now, I'll add a few more if I can do so without adding too much complexity. Mike "Silby" Silbersack