1. 16 4月, 2015 1 次提交
    • Y
      IB/mlx4: Alias GUID adding persistency support · 99ee4df6
      Yishai Hadas 提交于
      If the SM rejects an alias GUID request the PF driver keeps trying to acquire
      the specified GUID indefinitely, utilizing an exponential backoff scheme.
      
      Retrying is managed per GUID entry. Each entry that wasn't applied holds its
      next retry information. Retry requests to the SM consist of records of 8
      consecutive GUIDS. Each record that contains GUIDs requiring retries holds its
      next time-to-run based on the retry information of all its GUID entries. The
      record having the lowest retry time will run first when that retry time
      arrives.
      
      Since the method (SET or DELETE) as sent to the SM applies to all the GUIDs in
      the record, we must handle SET requests and DELETE requests in separate SM
      messages (one for SETs and the other for DELETEs).
      
      To avoid race conditions where a GUID entry request (set or delete) was
      modified after the SM request was sent, we save the method and the requested
      indices as part of the callback's context -- thus, only the requested indexes
      are evaluated when the response is received.
      
      When an GUID entry is approved we turn off its retry-required bit, this
      prevents redundant SM retries from occurring on that record.
      
      The port down event should be sent only when previously it was up. Likewise,
      the port up event should be sent only if previously the port was down.
      
      Synchronization was added around the flows that change entries and record state
      to prevent race conditions.
      Signed-off-by: NYishai Hadas <yishaih@mellanox.com>
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      99ee4df6
  2. 15 4月, 2015 39 次提交