sendfile(2) SF_NOPUSH flag proposal

[Terry Lambert]

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