• Jon Maloy's avatar
    tipc: add multipoint-to-point flow control · 04d7b574
    Jon Maloy authored
    We already have point-to-multipoint flow control within a group. But
    we even need the opposite; -a scheme which can handle that potentially
    hundreds of sources may try to send messages to the same destination
    simultaneously without causing buffer overflow at the recipient. This
    commit adds such a mechanism.
    
    The algorithm works as follows:
    
    - When a member detects a new, joining member, it initially set its
      state to JOINED and advertises a minimum window to the new member.
      This window is chosen so that the new member can send exactly one
      maximum sized message, or several smaller ones, to the recipient
      before it must stop and wait for an additional advertisement. This
      minimum window ADV_IDLE is set to 65 1kB blocks.
    
    - When a member receives the first data message from a JOINED member,
      it changes the state of the latter to ACTIVE, and advertises a larger
      window ADV_ACTIVE = 12 x ADV_IDLE blocks to the sender, so it can
      continue sending with minimal disturbances to the data flow.
    
    - The active members are kept in a dedicated linked list. Each time a
      message is received from an active member, it will be moved to the
      tail of that list. This way, we keep a record of which members have
      been most (tail) and least (head) recently active.
    
    - There is a maximum number (16) of permitted simultaneous active
      senders per receiver. When this limit is reached, the receiver will
      not advertise anything immediately to a new sender, but instead put
      it in a PENDING state, and add it to a corresponding queue. At the
      same time, it will pick the least recently active member, send it an
      advertisement RECLAIM message, and set this member to state
      RECLAIMING.
    
    - The reclaimee member has to respond with a REMIT message, meaning that
      it goes back to a send window of ADV_IDLE, and returns its unused
      advertised blocks beyond that value to the reclaiming member.
    
    - When the reclaiming member receives the REMIT message, it unlinks
      the reclaimee from its active list, resets its state to JOINED, and
      notes that it is now back at ADV_IDLE advertised blocks to that
      member. If there are still unread data messages sent out by
      reclaimee before the REMIT, the member goes into an intermediate
      state REMITTED, where it stays until the said messages have been
      consumed.
    
    - The returned advertised blocks can now be re-advertised to the
      pending member, which is now set to state ACTIVE and added to
      the active member list.
    
    - To be proactive, i.e., to minimize the risk that any member will
      end up in the pending queue, we start reclaiming resources already
      when the number of active members exceeds 3/4 of the permitted
      maximum.
    Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
    Acked-by: default avatarYing Xue <ying.xue@windriver.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    04d7b574
group.c 21.5 KB