From owner-freebsd-net Wed Sep 25 12:40:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C95537B406; Wed, 25 Sep 2002 12:40:32 -0700 (PDT) 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 B673543E3B; Wed, 25 Sep 2002 12:40:31 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.11.6/8.11.6) id g8PJdjr10039; Wed, 25 Sep 2002 12:39:45 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200209251939.g8PJdjr10039@ambrisko.com> Subject: Re: Fwd: mbuf chain In-Reply-To: <20020924212719.A42295@iguana.icir.org> To: Luigi Rizzo Date: Wed, 25 Sep 2002 12:39:45 -0700 (PDT) Cc: Prafulla Deuskar , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Luigi Rizzo writes: | On Tue, Sep 24, 2002 at 04:15:56PM -0700, Prafulla Deuskar wrote: | > Sorry for the cross-posting. | > ---------------------------- | > | > All, | > | > Is there a pre-set limit on maximum number of fragments in a | > mbuf chain ? | > | > I see 64 fragments with jumboframes (mtu 9000) using nttcp. | | aha... (this is related to the problem with the em driver and jumbo | frames, right ?) | | o limit that i know of. | And now i clearly see how the long chain might arise -- sosend puts | each write in one ro more mbufs, then down in the call chain, | sbappend() is called which in turn calls sbcompress(). The problem | is, for short writes on a TCP socket (say 128 bytes at a time) the | data goes into regular mbufs, not clusters, so sbcompress does not | have a chance to compress the chain because of lack of space in the | mbufs. | | A possible workaround would be to modify sbcompress to allocate | clusters replacing existing mbufs when such a situation exists. Various drivers have code to deal with this when the structure it is putting the frags into runs out :-( See a recent bug fix to the ste(4) gleaned from the fxp(4). This type of problem is probably lurking in other drivers. Unfortunately the ste(4) driver siliently failed and sent out truncated packets before the fix. When I instrumented the code while the system was hosting a CVS pserver checkout I saw the frag count go up to 10. Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message