Date: Wed, 28 May 2003 00:05:13 +0400 (MSD) From: Igor Sysoev <is@rambler-co.ru> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: arch@freebsd.org Subject: Re: sendfile(2) SF_NOPUSH flag proposal Message-ID: <Pine.BSF.4.21.0305280004120.49615-100000@is> In-Reply-To: <200305271801.h4RI12Qr066864@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 27 May 2003, Matthew Dillon wrote: > But considering the fairly high syscall overhead of sendfile() verses the > 1uS or so it takes to do a setsockopt(), implementing additional > flags in the sendfile() API to work around sendfile()'s inefficient > implementation of the header sending code SOLELY to avoid the additional > syscalls is not a good enough reason to change the API. It would just > be adding one hack on top of another with the side effect of the new > hack being visible in the API. This is bad. > > This (minor) problem *should* be solved by fixing the sendfile() > implementation itself. > It may well be that a reasonable solution would be to have sendfile() > itself set TCP_NOPUSH internally to wrap the header sending writev() > and the first data packet, then restore the previous state after > queueing the first data packet. That would still be a hack, but at least > it would be one that is not being made visible in the API. TCP_NOPUSH is required not only to coalesce the header and the first file part or the last file part and the trailer. It's also required to avoid the partially filled file packets. As I said already the file pages can be sent in 2x1460+1176 or 5x1460+892 packets. The implicit setting TF_NOPUSH in sendfile() and restoring it before return would not resolve completely partially filled file packets in the case of non-blocking socket. > Visible changes in APIs create porting headaches between UNIXes and > should be avoided whenever possible. I agree with portability issues but sendfile() is already very non-portable interface. sendfile() has different prototypes and functionality in all unicies. For example, Linux's sendfile() can not send headers or trailers, HP/UX's sendfile() allows to send only one header and one trailer (i.e. they are not iovec's), Solaris's sendfilev() allows to send combination of the several files and iovecs like WinXP's TransmitPackets(). Igor Sysoev http://sysoev.ru/en/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0305280004120.49615-100000>