Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
To: new-httpd@apache.org
Subject: Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
References: <Pine.LNX.4.21.0010030651240.9223-100000@koj>
From: Jeff Trawick <trawickj@bellsouth.net>
Date: 03 Oct 2000 10:34:08 -0400
In-Reply-To: rbb@covalent.net's message of "Tue,
 3 Oct 2000 06:57:32 -0700 (PDT)"
Message-ID: <m3g0megfj3.fsf@adsl-77-241-65.rdu.bellsouth.net>
Lines: 29

rbb@covalent.net writes:

> The reason it shouldn't do any coalescing, is that it really doesn't know
> enough about the network type to do the coalescing.  Assume we can swap
> out the filter that does the writing for a new filter that uses an ATM
> network.  The packet sizes on ethernet and ATM should probably be
> different.  If we coalesce above the core, this becomes a harder problem
> to solve.

I think the best we can do is give the TCP stack a nice bit of data to
work with at a time (8K-9K)...  For a modern stack, what is more
interesting is not the interface MTU but the PMTU.  Suppose we know
the PMTU (not gonna happen)...  This isn't too helpful because the
PMTU is almost always going to be much smaller than the amount of data
we'd want to pass the stack at once, so we're back to just giving the
stack a bunch of data at once.  

Yeah, we can go faster in contrived benchmark situations and a small
percentage of real world scenarios if the size of bunch-of-data is
close to the MTU of somebody's favorite medium, but that isn't going
to have any effect on normal data transmission.  And if the size of
bunch-of-data is a multiple of the MTU of a common medium that's cool
too because it will often help a little, but the point of this is that
we aren't really going to know how to adjust the size of bunch-of-data
on a connection-by-connection basis. 
-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...