1. 22 Sep, 2016 7 commits
    • David Howells's avatar
      rxrpc: Obtain RTT data by requesting ACKs on DATA packets · 50235c4b
      David Howells authored
      In addition to sending a PING ACK to gain RTT data, we can set the
      RXRPC_REQUEST_ACK flag on a DATA packet and get a REQUESTED-ACK ACK.  The
      ACK packet contains the serial number of the packet it is in response to,
      so we can look through the Tx buffer for a matching DATA packet.
      
      This requires that the data packets be stamped with the time of
      transmission as a ktime rather than having the resend_at time in jiffies.
      
      This further requires the resend code to do the resend determination in
      ktimes and convert to jiffies to set the timer.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      50235c4b
    • David Howells's avatar
      rxrpc: Add ktime_sub_ms() · 77f2efcb
      David Howells authored
      Add a ktime_sub_ms() to go with ktime_add_ms() and co. for use in AF_RXRPC
      RTT determination.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      77f2efcb
    • David Howells's avatar
      rxrpc: Expedite ping response transmission · 7aa51da7
      David Howells authored
      Expedite the transmission of a response to a PING ACK by sending it from
      sendmsg if one is pending.  We're most likely to see a PING ACK during the
      client call Tx phase as the other side may use it to determine a number of
      parameters, such as the client's receive window size, the RTT and whether
      the client is doing slow start (similar to RFC5681).
      
      If we don't expedite it, it's left to the background processing thread to
      transmit.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      7aa51da7
    • David Howells's avatar
      rxrpc: Send pings to get RTT data · 8e83134d
      David Howells authored
      Send a PING ACK packet to the peer when we get a new incoming call from a
      peer we don't have a record for.  The PING RESPONSE ACK packet will tell us
      the following about the peer:
      
       (1) its receive window size
      
       (2) its MTU sizes
      
       (3) its support for jumbo DATA packets
      
       (4) if it supports slow start (similar to RFC 5681)
      
       (5) an estimate of the RTT
      
      This is necessary because the peer won't normally send us an ACK until it
      gets to the Rx phase and we send it a packet, but we would like to know
      some of this information before we start sending packets.
      
      A pair of tracepoints are added so that RTT determination can be observed.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      8e83134d
    • David Howells's avatar
      rxrpc: Add per-peer RTT tracker · cf1a6474
      David Howells authored
      Add a function to track the average RTT for a peer.  Sources of RTT data
      will be added in subsequent patches.
      
      The RTT data will be useful in the future for determining resend timeouts
      and for handling the slow-start part of the Rx protocol.
      
      Also add a pair of tracepoints, one to log transmissions to elicit a
      response for RTT purposes and one to log responses that contribute RTT
      data.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cf1a6474
    • David Howells's avatar
      rxrpc: Add re-sent Tx annotation · f07373ea
      David Howells authored
      Add a Tx-phase annotation for packet buffers to indicate that a buffer has
      already been retransmitted.  This will be used by future congestion
      management.  Re-retransmissions of a packet don't affect the congestion
      window managment in the same way as initial retransmissions.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      f07373ea
    • David Howells's avatar
      rxrpc: Don't store the rxrpc header in the Tx queue sk_buffs · 5a924b89
      David Howells authored
      Don't store the rxrpc protocol header in sk_buffs on the transmit queue,
      but rather generate it on the fly and pass it to kernel_sendmsg() as a
      separate iov.  This reduces the amount of storage required.
      
      Note that the security header is still stored in the sk_buff as it may get
      encrypted along with the data (and doesn't change with each transmission).
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      5a924b89
  2. 21 Sep, 2016 33 commits