From owner-cvs-src@FreeBSD.ORG Wed Mar 26 23:46:15 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 EC2C137B405 for ; Wed, 26 Mar 2003 23:46:15 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id D79FE43FBD for ; Wed, 26 Mar 2003 23:46:13 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 68480 invoked from network); 27 Mar 2003 07:46:12 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 27 Mar 2003 07:46:12 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 27 Mar 2003 01:42:44 -0600 (CST) From: Mike Silbersack To: Maxime Henrion In-Reply-To: <20030327013224.P7674@odysseus.silby.com> Message-ID: <20030327014054.K7674@odysseus.silby.com> References: <200303260452.h2Q4quap015364@www.ambrisko.com> <20030326183351.GJ57674@elvis.mu.org> <20030327013224.P7674@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-25.7 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: Sam Leffler cc: src-committers@FreeBSD.org cc: Doug Ambrisko cc: cvs-all@FreeBSD.org cc: cvs-src@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: Thu, 27 Mar 2003 07:46:18 -0000 Er, and XL_MAXFRAGS won't change, that's part of the test code too. We may have to enhance MBUF_FRAG_TEST to get a real test of some drivers; as Sam informed me, bus_dmamap_load_mbuf coalesces adjacent fragments, thereby defeating the testing ability of MBUF_FRAG_TEST. I guess I'll work on that next. On Thu, 27 Mar 2003, Mike Silbersack wrote: > > Ok, I think I have m_defrag in a working state, please review. > > Changes from last time: > > - It supports infinitely long chains. > - It has a "goal" argument which is supposed to be a hint to tell m_defrag > how long the chain can be. It is currently ignored; someone may want to > honor this later for optimization purposes. > - I fixed up the error case in if_xl, it only runs if needed now > > At the top of the if_loop and if_xl patches are debugging code I used to > make it was working right, they're certainly not going in. > > m_defrag should be totally free of debug code. > > Dig in! > > Mike "Silby" Silbersack