Date: Tue, 27 May 2003 09:29:20 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Igor Sysoev <is@rambler-co.ru> Cc: arch@freebsd.org Subject: Re: sendfile(2) SF_NOPUSH flag proposal Message-ID: <3ED39260.27639328@mindspring.com> References: <Pine.BSF.4.21.0305271958430.49418-100000@is>
next in thread | previous in thread | raw e-mail | index | archive | help
Igor Sysoev wrote: > > Actually, the functionality can be implemented *without* going > > and implementing the API. It should really be contrlled already > > by the TCP_NODELAY option *not* having been set by the user, and, > > for last-block next-first-block coelescing, by TCP_NOPUSH *having* > > been set. > > It's not an implementing the API. It's an addition to the already existed > API - sendfile(2). sendfile(2) already has the flags parameter and this > parameter is currently unused and should be zero. I propose two sendfile(2) > flags - SF_NOPUSH and SF_PUSH. Why? Why not just fix the broken sendfile(2) implementation, instead? > > > 2) The new feature provides significant performance benefit. In this > > > case, I believe the overhead of calling setsockopt(2) is negligible > > > so the performance gain would be negligible. > > > > 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. > > TCP_NODELAY is not set. So there's no barrier to you fixing this by either breaking up tcp_output() into two functions, or lazy-calling tcp_output(), instead of aggreesively calling it between headers and file data and file data and trailers in sendfile(2). Right? No API change necessary? -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ED39260.27639328>