From owner-cvs-src@FreeBSD.ORG Tue Mar 25 15:44:53 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 C401337B401; Tue, 25 Mar 2003 15:44:53 -0800 (PST) Received: from ambrisko.com (adsl-64-174-51-42.dsl.snfc21.pacbell.net [64.174.51.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 645B043F85; Tue, 25 Mar 2003 15:44:52 -0800 (PST) (envelope-from ambrisko@www.ambrisko.com) Received: from www.ambrisko.com (localhost [127.0.0.1]) by ambrisko.com (8.12.6/8.12.6) with ESMTP id h2PNiphZ098879; Tue, 25 Mar 2003 15:44:51 -0800 (PST) (envelope-from ambrisko@www.ambrisko.com) Received: (from ambrisko@localhost) by www.ambrisko.com (8.12.6/8.12.6/Submit) id h2PNip18098878; Tue, 25 Mar 2003 15:44:51 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200303252344.h2PNip18098878@www.ambrisko.com> In-Reply-To: <20030324234234.T6129@odysseus.silby.com> To: Mike Silbersack Date: Tue, 25 Mar 2003 15:44:51 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=-3.3 required=5.0 tests=IN_REP_TO 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: Mike Silbersack cc: cvs-all@FreeBSD.org cc: src-committers@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: Tue, 25 Mar 2003 23:44:55 -0000 Mike Silbersack writes: | | FWIW, the two drivers I tested this with (if_xl and if_sis) both flunk. | if_xl tries to fix the situation, but fails, and if_sis goes totally | weird, eating mbufs and rendering the interface unuseable. | | I'll test more interfaces once I have these two fixed. This doesn't surprise me. I fixed this in the ste(4) driver. You can also make this happen to some extent by do a dd etc. into a connection with a small byte count. This makes it easier though. Most of this is probably due to a common cut-n-paste of other drivers. Might also look at tuning down the number of allowable frags in drivers. With 4 ste(4) chips on 3 ports consumed 1.5M of memory! I reduced this in the ste(4) driver as well. We might want to document a good rule of thumb for number of mbuf frags before de-fraging them. Unfortunately this seems to imply you might have to walk the mbuf chain twice. | Mike "Silby" Silbersack | | On Mon, 24 Mar 2003, Mike Silbersack wrote: | | > silby 2003/03/24 21:45:05 PST | > | > FreeBSD src repository | > | > Modified files: | > sys/conf options | > sys/netinet ip_output.c | > Log: | > Add the MBUF_FRAG_TEST option. When compiled in, this option | > allows you to tell ip_output to fragment all outgoing packets | > into mbuf fragments of size net.inet.ip.mbuf_frag_size bytes. | > This is an excellent way to test if network drivers can properly | > handle long mbuf chains being passed to them. | > | > net.inet.ip.mbuf_frag_size defaults to 0 (no fragmentation) | > so that you can at least boot before your network driver dies. :) | > | > Revision Changes Path | > 1.383 +1 -0 src/sys/conf/options | > 1.179 +30 -0 src/sys/netinet/ip_output.c