Re: sendfile(2) SF_NOPUSH flag proposal

From: Terry Lambert (tlambert2_at_mindspring.com)
Date: 05/27/03

  • Next message: Igor Sysoev: "Re: sendfile(2) SF_NOPUSH flag proposal" 
    Date: Mon, 26 May 2003 17:19:36 -0700
To: Igor Sysoev <is@rambler-co.ru>

    Igor Sysoev wrote:
    > sendfile(2) now has two drawbacks:

    Only two? ;^).

    > 1) it always sends the header, the file and the trailer in the separate
    > packets even their sizes allow to place all them in one packet.
    > For example the typical HTTP response header is less then an ethernet
    > packet and sendfile() sends it in first small packet.
    >
    > 2) often enough it sends 4K page in three packets: 1460, 1460 and 1176 bytes.
    >
    > 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.

    OK, basically what is happening is that the data is being
    pushed out as it's made available, and it's being made
    available in seperate chunks.

    The small file case is not really the optimum case for using
    the sendfile interface at all.

    The problem here is that you have a send queue depth limit
    on the sockets, and it's expected that the file will end up
    exceeding this, so it's going to get buffered anyway, due
    to a buffer size limit stall on the send side of the socket.

    > 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 don't see this as being terrifically useful; small files
    should probably just be mapped and written; the copy expense
    is still there for the headers and trailers, no matter what,
    and the file size itself is very small overhead, relatively
    speaking, for files small enough for this to be an issue.

    I also think your headers and trailers are very small, if
    they are fitting with the file contents in a single packet.
    I think this is atypical.

    On the other hand, if you want to add a flag for this, I say
    "knock yourself out" -- go ahead and add the flag; it's not
    really going to benefit you that much, but it's not going to
    really hurt any of the rest of us either, so there's really
    no reason to make you not do it. 8-).

    BTW: if you go ahead with this, you should verify that it
    also works for the trailers, etc., and you should probably
    skip it if you headers > transmit queue depth, or file size
    > transmit queue depth, or trailers > transmit queue depth.

    -- Terry
    _______________________________________________
    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: Igor Sysoev: "Re: sendfile(2) SF_NOPUSH flag proposal"

    Relevant Pages

    • Re: sendfile(2) SF_NOPUSH flag proposal
      ... > file in the process address space to mbufs, to the card. ... > packet, you are probably going to spend more on the headers ... I mean that if you have 230 bytes header then sendfile() will send it ...
      (freebsd-arch)
    • sendfile(2) SF_NOPUSH flag proposal
      ... packets even their sizes allow to place all them in one packet. ... For example the typical HTTP response header is less then an ethernet ... When I turn TCP_NOPUSH on just before sendfile() then it sends the header ... try the trailer) on FreeBSD 4.2 and 4.3 without src/sys/netinet/tcp_usrreq.c ...
      (freebsd-arch)
    • Re: xPC Binary Fifo Problem
      ... In general you'll be looking for one of the headers ... packet could trigger the code to think that it was the ... header of a different command. ... The problem I'm encountering is that the binary header FIFO ...
      (comp.soft-sys.matlab)
    • Re: xPC Binary Fifo Problem
      ... packet could trigger the code to think that it was the ... header of a different command. ... The problem I'm encountering is that the binary header FIFO ... under the serial system has problems with headers that start ...
      (comp.soft-sys.matlab)
    • Re: Is a HTTP header a clear text?
      ... getting the HTTP headers which is supposed to be clear text we're ... This is the whole captured packet we got by writing it in a file using ... tcp headers. ...
      (comp.os.linux.networking)