From owner-cvs-all@FreeBSD.ORG Tue Mar 25 21:23:38 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 D730A37B405 for ; Tue, 25 Mar 2003 21:23:37 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 5030343FAF for ; Tue, 25 Mar 2003 21:23:36 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 97516 invoked from network); 26 Mar 2003 05:23:35 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 26 Mar 2003 05:23:35 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 25 Mar 2003 23:20:11 -0600 (CST) From: Mike Silbersack To: Doug Ambrisko In-Reply-To: <200303260452.h2Q4quap015364@www.ambrisko.com> Message-ID: <20030325231814.L1448@odysseus.silby.com> References: <200303260452.h2Q4quap015364@www.ambrisko.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-26.2 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: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org 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: Wed, 26 Mar 2003 05:23:40 -0000 On Tue, 25 Mar 2003, Doug Ambrisko wrote: > | Hm, I suppose it would be pretty easy to tack together some statistics > | code which tracked how long the chains being sent to the drivers are. > > I did that in my testing, but just used a printf for debugging. > > | I've been pondering where the tradeoff between avoiding memory copies and > | doing excessive scatter / gather DMA lies. Perhaps we should be > | defragmenting any chain over a certain amount of length, no matter the > | limit imposed by the card. This sounds like a Terry question. :) > > Maybe an extent count could be used that said how long the chain is. > > As Sam mentioned having little things scattered around is not good thing. > Memory and CPU can be a lot faster then the I/O bus. > > Doug A. I think we could inexpensively walk the mbuf chain at the end of ip_output and do the counting there. Realistically, the same chain will be rewalked very soon afterword when the network card tries to set up the DMA transfers / etc. Mike "Silby" Silbersack