From owner-freebsd-net Thu Jul 11 16:31:42 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 6528437B400 for ; Thu, 11 Jul 2002 16:31:39 -0700 (PDT) Received: from kronos.networkrichmond.com (kronos.networkrichmond.com [64.240.180.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id A000443E09 for ; Thu, 11 Jul 2002 16:31:38 -0700 (PDT) (envelope-from kbyanc@posi.net) X-Provider: NetworkRichmond, Inc. http://www.networkrichmond.com/ Received: from localhost (kbyanc@localhost) by kronos.networkrichmond.com (8.9.3/8.9.3/antispam) with ESMTP id TAA51972; Thu, 11 Jul 2002 19:31:17 -0400 (EDT) Date: Thu, 11 Jul 2002 19:31:17 -0400 (EDT) From: Kelly Yancey X-Sender: kbyanc@kronos.networkrichmond.com To: Bosko Milekic Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters In-Reply-To: <20020711171255.A19014@unixdaemons.com> Message-ID: MIME-Version: 1.0 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 On Thu, 11 Jul 2002, Bosko Milekic wrote: > > On Thu, Jul 11, 2002 at 01:56:08PM -0700, Luigi Rizzo wrote: > > example: userland does an 8KB write, in the old case this requires > > 4 clusters, with the new one you end up using 4 clusters and stuff > > the remaining 16 bytes in a regular mbuf, then depending on the > > relative producer-consumer speed the next write will try to fill > > the mbuf and attach a new cluster, and so on... and when TCP hits > > these data-in-mbuf blocks will have to copy rather than reference > > the data blocks... > > > > Maybe it is irrelevant for performance, maybe it is not, > > i am not sure. > > I see what you're saying. I think that what this means is simply that > the `optimal' chunk of data to send is just a different size, so > instead of it being 8192 bytes, it'll be something like 8180 bytes or > something (to account for the counters). So, in other words, it > really depends on the frequency of exact 8192 sized sends in userland > applications. > ...or exactly 2k or 4k or 6k or 10k... > This is a good observation if we're going to be doing benchmarking, > but I'm not sure whether the repercussions are that important (unless, > as I said, there's a lot of applications that send exactly 8192 > byte chunks?). Basically, what we're doing is shifting the optimal > send size when using exactly 4 clusters, in this case, to (8192 - 16) > bytes. We can still send with exactly 4 clusters, it's just that the > optimal send size is a little different, that's all (this produces a > small shift in block send benchmark curves, usually). > Are you kidding? Benchmarks, presumably like every other piece of software produced by someone trying to get the most performance out of the system, are more likely to have power-of-two write buffers. Are you willing to risk that they didn't also just happen to pick a multiple of 2^11? Yes, it seems elegant to put the counters in the space that is normally unused for receive mbuf clusters, but you can't just blow off Luigi's point regarding the send side. Kelly -- Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message