05 Jan, 2017

1 commit

  • Fix the way enum values are translated into strings in AF_RXRPC
    tracepoints. The problem with just doing a lookup in a normal flat array
    of strings or chars is that external tracing infrastructure can't find it.
    Rather, TRACE_DEFINE_ENUM must be used.

    Also sort the enums and string tables to make it easier to keep them in
    order so that a future patch to __print_symbolic() can be optimised to try
    a direct lookup into the table first before iterating over it.

    A couple of _proto() macro calls are removed because they refered to tables
    that got moved to the tracing infrastructure. The relevant data can be
    found by way of tracing.

    Signed-off-by: David Howells

    David Howells
     

06 Oct, 2016

3 commits

  • We need to generate a DELAY ACK from the service end of an operation if we
    start doing the actual operation work and it takes longer than expected.
    This will hard-ACK the request data and allow the client to release its
    resources.

    To make this work:

    (1) We have to set the ack timer and propose an ACK when the call moves to
    the RXRPC_CALL_SERVER_ACK_REQUEST and clear the pending ACK and cancel
    the timer when we start transmitting the reply (the first DATA packet
    of the reply implicitly ACKs the request phase).

    (2) It must be possible to set the timer when the caller is holding
    call->state_lock, so split the lock-getting part of the timer function
    out.

    (3) Add trace notes for the ACK we're requesting and the timer we clear.

    Signed-off-by: David Howells

    David Howells
     
  • Separate the output of PING ACKs from the output of other sorts of ACK so
    that if we receive a PING ACK and schedule transmission of a PING RESPONSE
    ACK, the response doesn't get cancelled by a PING ACK we happen to be
    scheduling transmission of at the same time.

    If a PING RESPONSE gets lost, the other side might just sit there waiting
    for it and refuse to proceed otherwise.

    Signed-off-by: David Howells

    David Howells
     
  • Remove a duplicate const keyword.

    Signed-off-by: David Howells

    David Howells
     

30 Sep, 2016

2 commits

  • Keep that call timeouts as ktimes rather than jiffies so that they can be
    expressed as functions of RTT.

    Signed-off-by: David Howells

    David Howells
     
  • In rxrpc_send_data_packet() make the loss-injection path return through the
    same code as the transmission path so that the RTT determination is
    initiated and any future timer shuffling will be done, despite the packet
    having been binned.

    Whilst we're at it:

    (1) Add to the tx_data tracepoint an indication of whether or not we're
    retransmitting a data packet.

    (2) When we're deciding whether or not to request an ACK, rather than
    checking if we're in fast-retransmit mode check instead if we're
    retransmitting.

    (3) Don't invoke the lose_skb tracepoint when losing a Tx packet as we're
    not altering the sk_buff refcount nor are we just seeing it after
    getting it off the Tx list.

    (4) The rxrpc_skb_tx_lost note is then no longer used so remove it.

    (5) rxrpc_lose_skb() no longer needs to deal with rxrpc_skb_tx_lost.

    Signed-off-by: David Howells

    David Howells
     

25 Sep, 2016

4 commits

  • Implement RxRPC slow-start, which is similar to RFC 5681 for TCP. A
    tracepoint is added to log the state of the congestion management algorithm
    and the decisions it makes.

    Notes:

    (1) Since we send fixed-size DATA packets (apart from the final packet in
    each phase), counters and calculations are in terms of packets rather
    than bytes.

    (2) The ACK packet carries the equivalent of TCP SACK.

    (3) The FLIGHT_SIZE calculation in RFC 5681 doesn't seem particularly
    suited to SACK of a small number of packets. It seems that, almost
    inevitably, by the time three 'duplicate' ACKs have been seen, we have
    narrowed the loss down to one or two missing packets, and the
    FLIGHT_SIZE calculation ends up as 2.

    (4) In rxrpc_resend(), if there was no data that apparently needed
    retransmission, we transmit a PING ACK to ask the peer to tell us what
    its Rx window state is.

    Signed-off-by: David Howells

    David Howells
     
  • If we've sent all the request data in a client call but haven't seen any
    sign of the reply data yet, schedule an ACK to be sent to the server to
    find out if the reply data got lost.

    If the server hasn't yet hard-ACK'd the request data, we send a PING ACK to
    demand a response to find out whether we need to retransmit.

    If the server says it has received all of the data, we send an IDLE ACK to
    tell the server that we haven't received anything in the receive phase as
    yet.

    To make this work, a non-immediate PING ACK must carry a delay. I've chosen
    the same as the IDLE ACK for the moment.

    Signed-off-by: David Howells

    David Howells
     
  • Clear the ACK reason, ACK timer and resend timer when entering the client
    reply phase when the first DATA packet is received. New ACKs will be
    proposed once the data is queued.

    The resend timer is no longer relevant and we need to cancel ACKs scheduled
    to probe for a lost reply.

    Signed-off-by: David Howells

    David Howells
     
  • Send an ACK if we haven't sent one for the last two packets we've received.
    This keeps the other end apprised of where we've got to - which is
    important if they're doing slow-start.

    We do this in recvmsg so that we can dispatch a packet directly without the
    need to wake up the background thread.

    This should possibly be made configurable in future.

    Signed-off-by: David Howells

    David Howells
     

23 Sep, 2016

3 commits

  • Add a tracepoint to log proposed ACKs, including whether the proposal is
    used to update a pending ACK or is discarded in favour of an easlier,
    higher priority ACK.

    Whilst we're at it, get rid of the rxrpc_acks() function and access the
    name array directly. We do, however, need to validate the ACK reason
    number given to trace_rxrpc_rx_ack() to make sure we don't overrun the
    array.

    Signed-off-by: David Howells

    David Howells
     
  • Add a tracepoint to log call timer initiation, setting and expiry.

    Signed-off-by: David Howells

    David Howells
     
  • When the last packet of data to be transmitted on a call is queued, tx_top
    is set and then the RXRPC_CALL_TX_LAST flag is set. Unfortunately, this
    leaves a race in the ACK processing side of things because the flag affects
    the interpretation of tx_top and also allows us to start receiving reply
    data before we've finished transmitting.

    To fix this, make the following changes:

    (1) rxrpc_queue_packet() now sets a marker in the annotation buffer
    instead of setting the RXRPC_CALL_TX_LAST flag.

    (2) rxrpc_rotate_tx_window() detects the marker and sets the flag in the
    same context as the routines that use it.

    (3) rxrpc_end_tx_phase() is simplified to just shift the call state.
    The Tx window must have been rotated before calling to discard the
    last packet.

    (4) rxrpc_receiving_reply() is added to handle the arrival of the first
    DATA packet of a reply to a client call (which is an implicit ACK of
    the Tx phase).

    (5) The last part of rxrpc_input_ack() is reordered to perform Tx
    rotation, then soft-ACK application and then to end the phase if we've
    rotated the last packet. In the event of a terminal ACK, the soft-ACK
    application will be skipped as nAcks should be 0.

    (6) rxrpc_input_ackall() now has to rotate as well as ending the phase.

    In addition:

    (7) Alter the transmit tracepoint to log the rotation of the last packet.

    (8) Remove the no-longer relevant queue_reqack tracepoint note. The
    ACK-REQUESTED packet header flag is now set as needed when we actually
    transmit the packet and may vary by retransmission.

    Signed-off-by: David Howells

    David Howells
     

22 Sep, 2016

3 commits

  • 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: David Howells

    David Howells
     
  • 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: David Howells

    David Howells
     
  • 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: David Howells

    David Howells
     

17 Sep, 2016

5 commits


14 Sep, 2016

1 commit

  • call->rx_winsize should be initialised to the sysctl setting and the sysctl
    setting should be limited to the maximum we want to permit. Further, we
    need to place this in the ACK info instead of the sysctl setting.

    Furthermore, discard the idea of accepting the subpackets of a jumbo packet
    that lie beyond the receive window when the first packet of the jumbo is
    within the window. Just discard the excess subpackets instead. This
    allows the receive window to be opened up right to the buffer size less one
    for the dead slot.

    Signed-off-by: David Howells

    David Howells
     

08 Sep, 2016

1 commit

  • Rewrite the data and ack handling code such that:

    (1) Parsing of received ACK and ABORT packets and the distribution and the
    filing of DATA packets happens entirely within the data_ready context
    called from the UDP socket. This allows us to process and discard ACK
    and ABORT packets much more quickly (they're no longer stashed on a
    queue for a background thread to process).

    (2) We avoid calling skb_clone(), pskb_pull() and pskb_trim(). We instead
    keep track of the offset and length of the content of each packet in
    the sk_buff metadata. This means we don't do any allocation in the
    receive path.

    (3) Jumbo DATA packet parsing is now done in data_ready context. Rather
    than cloning the packet once for each subpacket and pulling/trimming
    it, we file the packet multiple times with an annotation for each
    indicating which subpacket is there. From that we can directly
    calculate the offset and length.

    (4) A call's receive queue can be accessed without taking locks (memory
    barriers do have to be used, though).

    (5) Incoming calls are set up from preallocated resources and immediately
    made live. They can than have packets queued upon them and ACKs
    generated. If insufficient resources exist, DATA packet #1 is given a
    BUSY reply and other DATA packets are discarded).

    (6) sk_buffs no longer take a ref on their parent call.

    To make this work, the following changes are made:

    (1) Each call's receive buffer is now a circular buffer of sk_buff
    pointers (rxtx_buffer) rather than a number of sk_buff_heads spread
    between the call and the socket. This permits each sk_buff to be in
    the buffer multiple times. The receive buffer is reused for the
    transmit buffer.

    (2) A circular buffer of annotations (rxtx_annotations) is kept parallel
    to the data buffer. Transmission phase annotations indicate whether a
    buffered packet has been ACK'd or not and whether it needs
    retransmission.

    Receive phase annotations indicate whether a slot holds a whole packet
    or a jumbo subpacket and, if the latter, which subpacket. They also
    note whether the packet has been decrypted in place.

    (3) DATA packet window tracking is much simplified. Each phase has just
    two numbers representing the window (rx_hard_ack/rx_top and
    tx_hard_ack/tx_top).

    The hard_ack number is the sequence number before base of the window,
    representing the last packet the other side says it has consumed.
    hard_ack starts from 0 and the first packet is sequence number 1.

    The top number is the sequence number of the highest-numbered packet
    residing in the buffer. Packets between hard_ack+1 and top are
    soft-ACK'd to indicate they've been received, but not yet consumed.

    Four macros, before(), before_eq(), after() and after_eq() are added
    to compare sequence numbers within the window. This allows for the
    top of the window to wrap when the hard-ack sequence number gets close
    to the limit.

    Two flags, RXRPC_CALL_RX_LAST and RXRPC_CALL_TX_LAST, are added also
    to indicate when rx_top and tx_top point at the packets with the
    LAST_PACKET bit set, indicating the end of the phase.

    (4) Calls are queued on the socket 'receive queue' rather than packets.
    This means that we don't need have to invent dummy packets to queue to
    indicate abnormal/terminal states and we don't have to keep metadata
    packets (such as ABORTs) around

    (5) The offset and length of a (sub)packet's content are now passed to
    the verify_packet security op. This is currently expected to decrypt
    the packet in place and validate it.

    However, there's now nowhere to store the revised offset and length of
    the actual data within the decrypted blob (there may be a header and
    padding to skip) because an sk_buff may represent multiple packets, so
    a locate_data security op is added to retrieve these details from the
    sk_buff content when needed.

    (6) recvmsg() now has to handle jumbo subpackets, where each subpacket is
    individually secured and needs to be individually decrypted. The code
    to do this is broken out into rxrpc_recvmsg_data() and shared with the
    kernel API. It now iterates over the call's receive buffer rather
    than walking the socket receive queue.

    Additional changes:

    (1) The timers are condensed to a single timer that is set for the soonest
    of three timeouts (delayed ACK generation, DATA retransmission and
    call lifespan).

    (2) Transmission of ACK and ABORT packets is effected immediately from
    process-context socket ops/kernel API calls that cause them instead of
    them being punted off to a background work item. The data_ready
    handler still has to defer to the background, though.

    (3) A shutdown op is added to the AF_RXRPC socket so that the AFS
    filesystem can shut down the socket and flush its own work items
    before closing the socket to deal with any in-progress service calls.

    Future additional changes that will need to be considered:

    (1) Make sure that a call doesn't hog the front of the queue by receiving
    data from the network as fast as userspace is consuming it to the
    exclusion of other calls.

    (2) Transmit delayed ACKs from within recvmsg() when we've consumed
    sufficiently more packets to avoid the background work item needing to
    run.

    Signed-off-by: David Howells

    David Howells
     

05 Sep, 2016

1 commit


11 Jun, 2016

1 commit

  • Limit the socket incoming call backlog queue size so that a remote client
    can't pump in sufficient new calls that the server runs out of memory. Note
    that this is partially theoretical at the moment since whilst the number of
    calls is limited, the number of packets trying to set up new calls is not.
    This will be addressed in a later patch.

    If the caller of listen() specifies a backlog INT_MAX, then they get the
    current maximum; anything else greater than max_backlog or anything
    negative incurs EINVAL.

    The limit on the maximum queue size can be set by:

    echo N >/proc/sys/net/rxrpc/max_backlog

    where 4
    Signed-off-by: David S. Miller

    David Howells
     

12 Apr, 2016

2 commits