Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Mon, 22 Aug 2005 14:51:12 +0100
From: Colm MacCarthaigh <colm@stdlib.net>
To: APR Development <dev@apr.apache.org>
Subject: Re: how to make apr_bucket_read() read only as much as I need?
Message-ID: <20050822135112.GA18391@stdlib.net>
Reply-To: colm@stdlib.net
References: <43053503.8020709@stason.org> <20050819062900.GB26855@redhat.com>
 <43058539.7080501@stason.org> <20050819082116.GA29545@redhat.com>
 <4306477E.30204@stason.org> <20050822125627.GB25876@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20050822125627.GB25876@redhat.com>
User-Agent: Mutt/1.5.9i

On Mon, Aug 22, 2005 at 01:56:27PM +0100, Joe Orton wrote:
> > Also while we are at it, do you remember why 8000 was chosen as the size 
> > of the buffer (I remember why it wasn't 8K, but I wonder why not 2k or 
> > 4k?) is it because it perfectly fits the memory page? but how do you 
> > ensure that it always starts at the page boundary and not hanging over the 
> > end of the previous page?
> 
> IIRC 8000 was picked because you can about that much in a single jumbo 
> ethernet frame on a gigE network, something like that.  

Hmmm, 8000 isn't a very good value if that was the reasoning. Most
jumboframe deployments are 9000 bytes end to end (based on Cisco's
choice of supporting 9128 bytes at transit level, and Broadcom's 9000
bytes at the lower end), giving payloads of 8944 bytes (assuming IPv4
and TCP). 

Jumboframe deployments of 16k arn't uncommon (Most Intel kit supports
16k for example) either, though not on the Internet.

-- 
Colm MacC�rthaigh                        Public Key: colm+pgp@stdlib.net