Date: Tue, 27 May 2003 09:02:51 -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: <3ED38C2B.DEA23AB8@mindspring.com> References: <Pine.BSF.4.21.0305271513120.46491-100000@is>
next in thread | previous in thread | raw e-mail | index | archive | help
Igor Sysoev wrote: > On Tue, 27 May 2003, Peter Jeremy wrote: > > 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. > > I think the calling setsockopt(TCP_NOPUSH, 1) syscall has huge overhead > as compared to several C operators inside sendfile(2). But this call should not be necessary. Internally, the sendfile(2) implementation should treat the headers + file contents + trailers as a single stream. Your problem is that the implementation of sendfile(2) sucks and is not doing this, not that you need to set TCP_NOPUSH to avoid seperation of three back-to-back transmits: you don't *have* three back-to-back transmits here, you have only *one* transmit. Would you expect a writev(2) operation to break up each of the chunks described by the vector into seperate back-to-back transmits? If not, why do you expect sendfile(2) to do it? > The turing TF_NOPUSH off has almost the same overhead as > setsockopt(TCP_NOPUSH, 0) if you need to call tcp_output(tp) inside > sendfile(2) and has no overhead at all if you do not need to call it. The problem is that you need to break tcp_output() into a couple of routines, OR you need to not call it on the headers, file data, and trailers seperately. > > At this stage, I would suggest that you need to do better than "the > > change is cheap" to justify adding this feature. Can you quantify > > the performance benefits, or provide some other justification? > > My point is not "the cheap change" but "the cheap overhead". I think we can all make up our own stories, where the overhead could become important enough for a specific application that we wouldn't complain about you eliminating it so you could do your application, as long as it doesn't negatively impact the rest of us (say, by adding non-standard sendfile(2) flags that no one else supports, if that isn't the only possible way to solve the problem). I don't think overhead is the issue, at this point: say we agree with you on overhead, for your particular application, and we are not against you solving your overhead problem: why exactly does the API have to change to fix the root cause of the problem? -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ED38C2B.DEA23AB8>