1. 09 Sep, 2020 38 commits
  2. 08 Sep, 2020 2 commits
    • David Howells's avatar
      rxrpc: Allow multiple client connections to the same peer · 288827d5
      David Howells authored
      Allow the number of parallel connections to a machine to be expanded from a
      single connection to a maximum of four.  This allows up to 16 calls to be
      in progress at the same time to any particular peer instead of 4.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      288827d5
    • David Howells's avatar
      rxrpc: Rewrite the client connection manager · 245500d8
      David Howells authored
      Rewrite the rxrpc client connection manager so that it can support multiple
      connections for a given security key to a peer.  The following changes are
      made:
      
       (1) For each open socket, the code currently maintains an rbtree with the
           connections placed into it, keyed by communications parameters.  This
           is tricky to maintain as connections can be culled from the tree or
           replaced within it.  Connections can require replacement for a number
           of reasons, e.g. their IDs span too great a range for the IDR data
           type to represent efficiently, the call ID numbers on that conn would
           overflow or the conn got aborted.
      
           This is changed so that there's now a connection bundle object placed
           in the tree, keyed on the same parameters.  The bundle, however, does
           not need to be replaced.
      
       (2) An rxrpc_bundle object can now manage the available channels for a set
           of parallel connections.  The lock that manages this is moved there
           from the rxrpc_connection struct (channel_lock).
      
       (3) There'a a dummy bundle for all incoming connections to share so that
           they have a channel_lock too.  It might be better to give each
           incoming connection its own bundle.  This bundle is not needed to
           manage which channels incoming calls are made on because that's the
           solely at whim of the client.
      
       (4) The restrictions on how many client connections are around are
           removed.  Instead, a previous patch limits the number of client calls
           that can be allocated.  Ordinarily, client connections are reaped
           after 2 minutes on the idle queue, but when more than a certain number
           of connections are in existence, the reaper starts reaping them after
           2s of idleness instead to get the numbers back down.
      
           It could also be made such that new call allocations are forced to
           wait until the number of outstanding connections subsides.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      245500d8