Date: Tue, 27 May 2003 11:14:07 -0700 (PDT) From: Marc Slemko <marcs@znep.com> To: arch@freebsd.org Subject: Re: sendfile(2) SF_NOPUSH flag proposal Message-ID: <Pine.NEB.4.53.0305271056180.28029@rhombus.znep.com> In-Reply-To: <3ED3844F.713FB360@mindspring.com> References: <20030526201740.GA22178@cirb503493.alcatel.com.au> <3ED3844F.713FB360@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 27 May 2003, Terry Lambert wrote: > The overhead of toggling it would be costly. However, I really > don't understand why he isn't just not setting TCP_NODELAY in > the first place, since it's an affirmative option, and then > leaaving the socket alone to act like it's supposed to act. Given the bug in FreeBSD's sendfile() that results in it sending the headers in a separate segment, then just leaving Nagle enabled will destroy your performance if you are implementing a protocol such as HTTP with persistent (pipelined or not) connections due to the interaction betwteen Nagle and delayed ack. However, that is somewhat of a moot point for HTTP anyway because if you support pipelined requests then for the most efficient implementation of HTTP on the network layer you need to ensure that the response headers and body from multiple requests can be coalesced into the same packet. When using sendfile(), this means you have to control TCP_NOPUSH yourself, even if sendfile coalesced headers, data, and trailers. sendfile() still should be fixed to properly coalesce them.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.4.53.0305271056180.28029>