• S
    tcp: track application-limited rate samples · d7722e85
    Soheil Hassas Yeganeh 提交于
    This commit adds code to track whether the delivery rate represented
    by each rate_sample was limited by the application.
    
    Upon each transmit, we store in the is_app_limited field in the skb a
    boolean bit indicating whether there is a known "bubble in the pipe":
    a point in the rate sample interval where the sender was
    application-limited, and did not transmit even though the cwnd and
    pacing rate allowed it.
    
    This logic marks the flow app-limited on a write if *all* of the
    following are true:
    
      1) There is less than 1 MSS of unsent data in the write queue
         available to transmit.
    
      2) There is no packet in the sender's queues (e.g. in fq or the NIC
         tx queue).
    
      3) The connection is not limited by cwnd.
    
      4) There are no lost packets to retransmit.
    
    The tcp_rate_check_app_limited() code in tcp_rate.c determines whether
    the connection is application-limited at the moment. If the flow is
    application-limited, it sets the tp->app_limited field. If the flow is
    application-limited then that means there is effectively a "bubble" of
    silence in the pipe now, and this silence will be reflected in a lower
    bandwidth sample for any rate samples from now until we get an ACK
    indicating this bubble has exited the pipe: specifically, until we get
    an ACK for the next packet we transmit.
    
    When we send every skb we record in scb->tx.is_app_limited whether the
    resulting rate sample will be application-limited.
    
    The code in tcp_rate_gen() checks to see when it is safe to mark all
    known application-limited bubbles of silence as having exited the
    pipe. It does this by checking to see when the delivered count moves
    past the tp->app_limited marker. At this point it zeroes the
    tp->app_limited marker, as all known bubbles are out of the pipe.
    
    We make room for the tx.is_app_limited bit in the skb by borrowing a
    bit from the in_flight field used by NV to record the number of bytes
    in flight. The receive window in the TCP header is 16 bits, and the
    max receive window scaling shift factor is 14 (RFC 1323). So the max
    receive window offered by the TCP protocol is 2^(16+14) = 2^30. So we
    only need 30 bits for the tx.in_flight used by NV.
    Signed-off-by: NVan Jacobson <vanj@google.com>
    Signed-off-by: NNeal Cardwell <ncardwell@google.com>
    Signed-off-by: NYuchung Cheng <ycheng@google.com>
    Signed-off-by: NNandita Dukkipati <nanditad@google.com>
    Signed-off-by: NEric Dumazet <edumazet@google.com>
    Signed-off-by: NSoheil Hassas Yeganeh <soheil@google.com>
    Signed-off-by: NDavid S. Miller <davem@davemloft.net>
    d7722e85
tcp_minisocks.c 26.1 KB