From owner-freebsd-net Tue Sep 24 21:27:21 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 32A3137B401; Tue, 24 Sep 2002 21:27:20 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD76B43E4A; Tue, 24 Sep 2002 21:27:19 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g8P4RJIb042448; Tue, 24 Sep 2002 21:27:19 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g8P4RJ3R042447; Tue, 24 Sep 2002 21:27:19 -0700 (PDT) (envelope-from rizzo) Date: Tue, 24 Sep 2002 21:27:19 -0700 From: Luigi Rizzo To: Prafulla Deuskar Cc: freebsd-net@FreeBSD.ORG Subject: Re: Fwd: mbuf chain Message-ID: <20020924212719.A42295@iguana.icir.org> References: <20020924161556.A63584@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020924161556.A63584@hub.freebsd.org>; from pdeuskar@FreeBSD.ORG on Tue, Sep 24, 2002 at 04:15:56PM -0700 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 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. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message