Re: sendfile(2) SF_NOPUSH flag proposal

From: Peter Jeremy (peterjeremy_at_optushome.com.au)
Date: 05/26/03

  • Next message: M. Warner Losh: "Re: New bootloader!" 
    Date: Tue, 27 May 2003 06:17:41 +1000
To: Igor Sysoev <is@rambler-co.ru>

    On Mon, May 26, 2003 at 09:41:50PM +0400, Igor Sysoev wrote:
    >sendfile(2) now has two drawbacks:
    [IP frames are not always full]
    ...
    >When I turn TCP_NOPUSH on just before sendfile() then it sends the header
    >and the first part of the file in one 1460 bytes packet.
    >Besides it sends file pages in the full ethernet 1460 bytes packets.
    >When sendfile() completed or returned EAGAIN (I use non-blocking sockets)
    >I turn TCP_NOPUSH off and the remaining file part is flushed to client.
    >Without turing off the remaining file part is delayed for 5 seconds.
    ...
    >So here is a proposal. We can introduce a sendfile(2) flag, i.e. SF_NOPUSH
    >that will turn TF_NOPUSH on before the sending and turn it off just
    >before return. It allows to save two syscalls on each sendfile() call
    >and it's especially useful with non-blocking sockets - they can cause many
    >sendfile() calls.

    I'm less certain of the benefits of this - particularly in the non-
    blocking case. As I understand your proposal, your patch would turn
    off TF_NOPUSH just before returning EAGAIN. At this point, the TCP
    send buffer is full so packets should start being sent immediately.
    The last data in the send buffer may not comprise a complete frame so
    it should not be sent, but left queued to be merged with the next
    sendfile(2). Once SO_SNDLOWAT bytes are available in the send buffer,
    the socket will become writable, allowing a further sendfile(2) call.
    As long as SO_SNDLOWAT is at least one frame smaller than SO_SNDBUF,
    there should not be any send delay caused by TF_NOPUSH being set.

    I believe TF_NOPUSH should be set at the beginning of a transaction
    (or when the socket is opened) and cleared at the end of a transaction
    (or implicitly by close()ing the socket).

    Peter
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: M. Warner Losh: "Re: New bootloader!"

    Relevant Pages

    • Re: sendfile(2) SF_NOPUSH flag proposal
      ... It allows to save two syscalls on each sendfile() call ... > send buffer is full so packets should start being sent immediately. ... > the socket will become writable, ... > and cleared at the end of a transaction ...
      (freebsd-arch)
    • Re: Update: Debox sendfile modifications
      ... > that says that sendfile() had started the reading a page. ... > a socket buffer space. ... When the page had been read this flag is reset. ...
      (freebsd-hackers)
    • Re: complement to sendfile()?
      ... My program receives data from the socket and writes it to a file -- with the ... Is there anything zero-copying like sendfile() for the socket->file direction? ... This is because network buffers can be made ...
      (freebsd-net)
    • Re: Update: Debox sendfile modifications
      ... > I think it can done in the following way - a socket should have flag ... > that says that sendfile() had started the reading a page. ... When the page had been read this flag is reset. ...
      (freebsd-hackers)
    • Re: Update: Debox sendfile modifications
      ... >> The current sendfile() implementation works with sockets only. ... >> it allows to minimize a data copy in http and ftp servers. ... >> data from a socket to a file) is useless. ... To see the perfomance impact of using sendfilein http or ftp server ...
      (freebsd-hackers)