1. 15 Jun, 2016 1 commit
    • Jon Paul Maloy's avatar
      tipc: add neighbor monitoring framework · 35c55c98
      Jon Paul Maloy authored
      
      
      TIPC based clusters are by default set up with full-mesh link
      connectivity between all nodes. Those links are expected to provide
      a short failure detection time, by default set to 1500 ms. Because
      of this, the background load for neighbor monitoring in an N-node
      cluster increases with a factor N on each node, while the overall
      monitoring traffic through the network infrastructure increases at
      a ~(N * (N - 1)) rate. Experience has shown that such clusters don't
      scale well beyond ~100 nodes unless we significantly increase failure
      discovery tolerance.
      
      This commit introduces a framework and an algorithm that drastically
      reduces this background load, while basically maintaining the original
      failure detection times across the whole cluster. Using this algorithm,
      background load will now grow at a rate of ~(2 * sqrt(N)) per node, and
      at ~(2 * N * sqrt(N)) in traffic overhead. As an example, each node will
      now have to actively monitor 38 neighbors in a 400-node cluster, instead
      of as before 399.
      
      This "Overlapping Ring Supervision Algorithm" is completely distributed
      and employs no centralized or coordinated state. It goes as follows:
      
      - Each node makes up a linearly ascending, circular list of all its N
        known neighbors, based on their TIPC node identity. This algorithm
        must be the same on all nodes.
      
      - The node then selects the next M = sqrt(N) - 1 nodes downstream from
        itself in the list, and chooses to actively monitor those. This is
        called its "local monitoring domain".
      
      - It creates a domain record describing the monitoring domain, and
        piggy-backs this in the data area of all neighbor monitoring messages
        (LINK_PROTOCOL/STATE) leaving that node. This means that all nodes in
        the cluster eventually (default within 400 ms) will learn about
        its monitoring domain.
      
      - Whenever a node discovers a change in its local domain, e.g., a node
        has been added or has gone down, it creates and sends out a new
        version of its node record to inform all neighbors about the change.
      
      - A node receiving a domain record from anybody outside its local domain
        matches this against its own list (which may not look the same), and
        chooses to not actively monitor those members of the received domain
        record that are also present in its own list. Instead, it relies on
        indications from the direct monitoring nodes if an indirectly
        monitored node has gone up or down. If a node is indicated lost, the
        receiving node temporarily activates its own direct monitoring towards
        that node in order to confirm, or not, that it is actually gone.
      
      - Since each node is actively monitoring sqrt(N) downstream neighbors,
        each node is also actively monitored by the same number of upstream
        neighbors. This means that all non-direct monitoring nodes normally
        will receive sqrt(N) indications that a node is gone.
      
      - A major drawback with ring monitoring is how it handles failures that
        cause massive network partitionings. If both a lost node and all its
        direct monitoring neighbors are inside the lost partition, the nodes in
        the remaining partition will never receive indications about the loss.
        To overcome this, each node also chooses to actively monitor some
        nodes outside its local domain. Those nodes are called remote domain
        "heads", and are selected in such a way that no node in the cluster
        will be more than two direct monitoring hops away. Because of this,
        each node, apart from monitoring the member of its local domain, will
        also typically monitor sqrt(N) remote head nodes.
      
      - As an optimization, local list status, domain status and domain
        records are marked with a generation number. This saves senders from
        unnecessarily conveying  unaltered domain records, and receivers from
        performing unneeded re-adaptations of their node monitoring list, such
        as re-assigning domain heads.
      
      - As a measure of caution we have added the possibility to disable the
        new algorithm through configuration. We do this by keeping a threshold
        value for the cluster size; a cluster that grows beyond this value
        will switch from full-mesh to ring monitoring, and vice versa when
        it shrinks below the value. This means that if the threshold is set to
        a value larger than any anticipated cluster size (default size is 32)
        the new algorithm is effectively disabled. A patch set for altering the
        threshold value and for listing the table contents will follow shortly.
      
      - This change is fully backwards compatible.
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      35c55c98
  2. 14 May, 2015 1 commit
    • Jon Paul Maloy's avatar
      tipc: simplify include dependencies · a6bf70f7
      Jon Paul Maloy authored
      
      
      When we try to add new inline functions in the code, we sometimes
      run into circular include dependencies.
      
      The main problem is that the file core.h, which really should be at
      the root of the dependency chain, instead is a leaf. I.e., core.h
      includes a number of header files that themselves should be allowed
      to include core.h. In reality this is unnecessary, because core.h does
      not need to know the full signature of any of the structs it refers to,
      only their type declaration.
      
      In this commit, we remove all dependencies from core.h towards any
      other tipc header file.
      
      As a consequence of this change, we can now move the function
      tipc_own_addr(net) from addr.c to addr.h, and make it inline.
      
      There are no functional changes in this commit.
      Reviewed-by: default avatarErik Hugne <erik.hugne@ericsson.com>
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a6bf70f7
  3. 29 Mar, 2015 1 commit
    • Jon Paul Maloy's avatar
      tipc: fix two bugs in secondary destination lookup · d482994f
      Jon Paul Maloy authored
      
      
      A message sent to a node after a successful name table lookup may still
      find that the destination socket has disappeared, because distribution
      of name table updates is non-atomic. If so, the message will be rejected
      back to the sender with error code TIPC_ERR_NO_PORT. If the source
      socket of the message has disappeared in the meantime, the message
      should be dropped.
      
      However, in the currrent code, the message will instead be subject to an
      unwanted tertiary lookup, because the function tipc_msg_lookup_dest()
      doesn't check if there is an error code present in the message before
      performing the lookup. In the worst case, the message may now find the
      old destination again, and be redirected once more, instead of being
      dropped directly as it should be.
      
      A second bug in this function is that the "prev_node" field in the message
      is not updated after successful lookup, something that may have
      unpredictable consequences.
      
      The problems arising from those bugs occur very infrequently.
      
      The third change in this function; the test on msg_reroute_msg_cnt() is
      purely cosmetic, reflecting that the returned value never can be negative.
      
      This commit corrects the two bugs described above.
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d482994f
  4. 12 Jan, 2015 4 commits
  5. 13 Feb, 2014 1 commit
  6. 30 Apr, 2012 1 commit
    • Paul Gortmaker's avatar
      tipc: compress out gratuitous extra carriage returns · 617d3c7a
      Paul Gortmaker authored
      
      
      Some of the comment blocks are floating in limbo between two
      functions, or between blocks of code.  Delete the extra line
      feeds between any comment and its associated following block
      of code, to be consistent with the majority of the rest of
      the kernel.  Also delete trailing newlines at EOF and fix
      a couple trivial typos in existing comments.
      
      This is a 100% cosmetic change with no runtime impact.  We get
      rid of over 500 lines of non-code, and being blank line deletes,
      they won't even show up as noise in git blame.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      617d3c7a
  7. 19 Apr, 2012 1 commit
    • Allan Stephens's avatar
      tipc: Add routines for safe checking of node's network address · 336ebf5b
      Allan Stephens authored
      
      
      Introduces routines that test whether a given network address is
      equal to a node's own network address or if it lies within the node's
      own network cluster, and which work properly regardless of whether
      the node is using the default network address <0.0.0> or a non-zero
      network address that is assigned later on. In essence, these routines
      ensure that address <0.0.0> is treated as an alias for "this node",
      regardless of which network address the node is actually using.
      
      Old users of the pre-existing more strict match in_own_cluster()
      have been accordingly redirected to what is now called
      in_own_cluster_exact() --- which does not extend matching to <0,0,0>.
      Signed-off-by: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      336ebf5b
  8. 10 May, 2011 1 commit
  9. 13 Mar, 2011 1 commit
  10. 01 Jan, 2011 2 commits
  11. 13 May, 2010 2 commits
  12. 08 Feb, 2008 1 commit
  13. 11 Feb, 2007 1 commit
  14. 17 Jan, 2006 1 commit
  15. 12 Jan, 2006 4 commits