httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <>
Subject Re: PATCH: lazy initialization of TCP_NODELAY (workaround for 2.6 TCP_CORK problem)
Date Fri, 26 Aug 2005 08:59:56 GMT
On Fri, Aug 26, 2005 at 01:23:15AM -0700, Brian Pane wrote:
> On Aug 26, 2005, at 12:55 AM, Joe Orton wrote:
> >On Fri, Aug 26, 2005 at 12:42:19AM -0700, Brian Pane wrote:
> >
> >>The attached patch delays the setting of TCP_NODELAY on client
> >>connections until the first time core_output_filter has to do a
> >>writev_it_all() or emulate_sendfile(). My motivation for this is to
> >>work around the TCP_NODELAY/TCP_CORK problem in Linux 2.6.  However,
> >>it also will save a couple of syscalls for any request that is  
> >>handled
> >>with sendfile(2).
> >>
> >
> >This will actually end up being *more* expensive on 2.6 systems in the
> >long run, though, right?  I'm not convinced this is a good idea.  With
> >APR changed to allow setting TCP_CORK and TCP_NODELAY at the same time
> >with 2.6, it is cheaper to just set TCP_NODELAY once on the listening
> >socket and never have to touch it again.
> I didn't think it was actually possible for APR to allow TCP_CORK and  
> at the same time.  From the tcp(7) manual page on my FC4 installation,

That's out of date yes, see recent thread ;)

All 2.6.x kernels do allow setting both TCP_CORK and TCP_NODELAY at the 
same time.

All current 2.6.x kernels have the bug in TCP_CORK handling which means 
that if TCP_NODELAY was ever enabled on the socket, TCP_CORK will not 
take effect.

The fix for that was in the 2.6.13-rc7 release, for the curious:;a=commit;h=89ebd197eb2cd31d6187db344d5117064e19fdde

> If it's possible to use both TCP_CORK and TCP_NODELAY on the same
> socket in 2.6.13 or later (assuming that's when the fix for the current
> NODELAY toggling problem becomes available), then yes, my lazy
> evaluation approach will be less efficient than just setting TCP_NODELAY
> on the listener socket--for requests that don't use sendfile.
> For requests that do use sendfile, I think the logic implemented by my 
> patch will be optimal for both 2.6.1-2.6.12 and 2.6.13+

To be clear this is only a partial workaround for the kernel bug: if at 
any time something is sent on the connection which requires enabling 
TCP_NODELAY, any subsequent TCP_CORKs will have no effect.

Given that fact I'm not convinced it's worth changing httpd: this is (1) 
a kernel bug and (2) an APR lack-of-feature; with both of those things 
fixed the current httpd code is perfectly correct.


View raw message