• 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
conn_client.c 28.5 KB