Date: Tue, 24 Sep 2002 21:27:19 -0700 From: Luigi Rizzo <rizzo@icir.org> To: Prafulla Deuskar <pdeuskar@FreeBSD.ORG> Cc: freebsd-net@FreeBSD.ORG Subject: Re: Fwd: mbuf chain Message-ID: <20020924212719.A42295@iguana.icir.org> In-Reply-To: <20020924161556.A63584@hub.freebsd.org>; from pdeuskar@FreeBSD.ORG on Tue, Sep 24, 2002 at 04:15:56PM -0700 References: <20020924161556.A63584@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020924212719.A42295>