1. 24 May, 2018 7 commits
  2. 22 May, 2018 3 commits
    • Steve Wise's avatar
      RDMA/CMA: add rdma_iw_cm_id() and rdma_res_to_id() helpers · fbdb0a91
      Steve Wise authored
      Add a helper function for iwarp drivers to be able to map an
      rdma_cm_id to an iw_cm_id.  This is useful for dumping driver specific
      NLDEV/RESTRACK connection state.
      
      Add a helper to return the rdma_cm_id pointer from the rdma_restack
      pointer.  This is needed for rdma drivers to map a res entry back to
      the public rdma_cm_id struct.
      Signed-off-by: default avatarSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      fbdb0a91
    • Steve Wise's avatar
      iw_cxgb4: always set iw_cm_id.provider_data · b06f2efd
      Steve Wise authored
      In active side connections, the provider_data field is not
      getting set.  This will be used in a subsequent patch to dump
      state, so always set it.
      Signed-off-by: default avatarSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      b06f2efd
    • Doug Ledford's avatar
      RDMA/ipoib: Update paths on CLIENT_REREG/SM_CHANGE events · fa9391db
      Doug Ledford authored
      We do a light flush on CLIENT_REREG and SM_CHANGE events.  This goes
      through and marks paths invalid. But we weren't always checking for this
      validity when we needed to, and so we could keep using a path marked
      invalid.  What's more, once we establish a path with a valid ah, we put
      a pointer to the ah in the neigh struct directly, so even if we mark the
      path as invalid, as long as the neigh has a direct pointer to the ah, it
      keeps using the old, outdated ah.
      
      To fix this we do several things.
      
      1) Put the valid flag in the ah instead of the path struct, so when we
      put the ah pointer directly in the neigh struct, we can easily check the
      validity of the ah on send events.
      2) Check the neigh->ah and neigh->ah->valid elements in the needed
      places, and if we have an ah, but it's invalid, then invoke a refresh of
      the ah.
      3) Fix the various places that check for path, but didn't check for
      path->valid (now path->ah && path->ah->valid).
      Reported-by: default avatarEvgenii Smirnov <evgenii.smirnov@profitbricks.com>
      Fixes: ee1e2c82 ("IPoIB: Refresh paths instead of flushing them on SM change events")
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      fa9391db
  3. 17 May, 2018 10 commits
  4. 16 May, 2018 4 commits
  5. 15 May, 2018 8 commits
  6. 09 May, 2018 8 commits
    • Brian Welty's avatar
      IB/{hfi1, qib, rdmavt}: Move logic to allocate receive WQE into rdmavt · 832369fa
      Brian Welty authored
      Moving receive-side WQE allocation logic into rdmavt will allow
      further code reuse between qib and hfi1 drivers.
      Reviewed-by: default avatarMike Marciniszyn <mike.marciniszyn@intel.com>
      Reviewed-by: default avatarDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: default avatarBrian Welty <brian.welty@intel.com>
      Signed-off-by: default avatarHarish Chegondi <harish.chegondi@intel.com>
      Signed-off-by: default avatarDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      832369fa
    • Sebastian Sanchez's avatar
      IB/{hfi1, rdmavt, qib}: Implement CQ completion vector support · 5d18ee67
      Sebastian Sanchez authored
      Currently the driver doesn't support completion vectors. These
      are used to indicate which sets of CQs should be grouped together
      into the same vector. A vector is a CQ processing thread that
      runs on a specific CPU.
      
      If an application has several CQs bound to different completion
      vectors, and each completion vector runs on different CPUs, then
      the completion queue workload is balanced. This helps scale as more
      nodes are used.
      
      Implement CQ completion vector support using a global workqueue
      where a CQ entry is queued to the CPU corresponding to the CQ's
      completion vector. Since the workqueue is global, it's guaranteed
      to always be there when queueing CQ entries; Therefore, the RCU
      locking for cq->rdi->worker in the hot path is superfluous.
      
      Each completion vector is assigned to a different CPU. The number of
      completion vectors available is computed by taking the number of
      online, physical CPUs from the local NUMA node and subtracting the
      CPUs used for kernel receive queues and the general interrupt.
      Special use cases:
      
        * If there are no CPUs left for completion vectors, the same CPU
          for the general interrupt is used; Therefore, there would only
          be one completion vector available.
      
        * For multi-HFI systems, the number of completion vectors available
          for each device is the total number of completion vectors in
          the local NUMA node divided by the number of devices in the same
          NUMA node. If there's a division remainder, the first device to
          get initialized gets an extra completion vector.
      
      Upon a CQ creation, an invalid completion vector could be specified.
      Handle it as follows:
      
        * If the completion vector is less than 0, set it to 0.
      
        * Set the completion vector to the result of the passed completion
          vector moded with the number of device completion vectors
          available.
      Reviewed-by: default avatarMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: default avatarSebastian Sanchez <sebastian.sanchez@intel.com>
      Signed-off-by: default avatarDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      5d18ee67
    • Sebastian Sanchez's avatar
      IB/hfi1: Create common functions for affinity CPU mask operations · cf38ea10
      Sebastian Sanchez authored
      CPU masks are used to keep track of affinity assignments for IRQs
      and processes. Operations performed on these affinity CPU masks are
      duplicated throughout the code.
      
      Create common functions for affinity CPU mask operations to remove
      duplicate code.
      Reviewed-by: default avatarMichael J. Ruhl <michael.j.ruhl@intel.com>
      Signed-off-by: default avatarSebastian Sanchez <sebastian.sanchez@intel.com>
      Signed-off-by: default avatarDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      cf38ea10
    • Sebastian Sanchez's avatar
      IB/hfi1: Optimize kthread pointer locking when queuing CQ entries · af8aab71
      Sebastian Sanchez authored
      All threads queuing CQ entries on different CQs are unnecessarily
      synchronized by a spin lock to check if the CQ kthread worker hasn't
      been destroyed before queuing an CQ entry.
      
      The lock used in 6efaf10f ("IB/rdmavt: Avoid queuing work into a
      destroyed cq kthread worker") is a device global lock and will have
      poor performance at scale as completions are entered from a large
      number of CPUs.
      
      Convert to use RCU where the read side of RCU is rvt_cq_enter() to
      determine that the worker is alive prior to triggering the
      completion event.
      Apply write side RCU semantics in rvt_driver_cq_init() and
      rvt_cq_exit().
      
      Fixes: 6efaf10f ("IB/rdmavt: Avoid queuing work into a destroyed cq kthread worker")
      Cc: <stable@vger.kernel.org> # 4.14.x
      Reviewed-by: default avatarMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: default avatarSebastian Sanchez <sebastian.sanchez@intel.com>
      Signed-off-by: default avatarDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      af8aab71
    • Kamenee Arumugam's avatar
      IB/Hfi1: Read CCE Revision register to verify the device is responsive · c872a1f9
      Kamenee Arumugam authored
      When Hfi1 device is unresponsive, reading the RcvArrayCnt register
      will return all 1's. This value is then used to remap chip's RcvArray.
      The incorrect all ones value used in remapping RcvArray
      will cause warn on as shown by trace below:
      
      [<ffffffff81685eac>] dump_stack+0x19/0x1b
      [<ffffffff81085820>] warn_slowpath_common+0x70/0xb0
      [<ffffffff810858bc>] warn_slowpath_fmt+0x5c/0x80
      [<ffffffff81065c29>] __ioremap_caller+0x279/0x320
      [<ffffffff8142873c>] ? _dev_info+0x6c/0x90
      [<ffffffffa021d155>] ? hfi1_pcie_ddinit+0x1d5/0x330 [hfi1]
      [<ffffffff81065d62>] ioremap_wc+0x32/0x40
      [<ffffffffa021d155>] hfi1_pcie_ddinit+0x1d5/0x330 [hfi1]
      [<ffffffffa0204851>] hfi1_init_dd+0x1d1/0x2440 [hfi1]
      [<ffffffff813503dc>] ? pci_write_config_word+0x1c/0x20
      
      Read CCE revision register first to verify that WFR device is
      responsive. If the read return "all ones", bail out from init
      and fail the driver load.
      Reviewed-by: default avatarMike Marciniszyn <mike.marciniszyn@intel.com>
      Reviewed-by: default avatarMichael J. Ruhl <michael.j.ruhl@intel.com>
      Signed-off-by: default avatarKamenee Arumugam <kamenee.arumugam@intel.com>
      Signed-off-by: default avatarDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      c872a1f9
    • Mitko Haralanov's avatar
      IB/hfi1: Rework fault injection machinery · a74d5307
      Mitko Haralanov authored
      The packet fault injection code present in the HFI1 driver had some
      issues which not only fragment the code but also created user
      confusion. Furthermore, it suffered from the following issues:
      
        1. The fault_packet method only worked for received packets. This
           meant that the only fault injection mode available for sent
           packets is fault_opcode, which did not allow for random packet
           drops on all egressing packets.
        2. The mask available for the fault_opcode mode did not really work
           due to the fact that the opcode values are not bits in a bitmask but
           rather sequential integer values. Creating a opcode/mask pair that
           would successfully capture a set of packets was nearly impossible.
        3. The code was fragmented and used too many debugfs entries to
           operate and control. This was confusing to users.
        4. It did not allow filtering fault injection on a per direction basis -
           egress vs. ingress.
      
      In order to improve or fix the above issues, the following changes have
      been made:
      
         1. The fault injection methods have been combined into a single fault
            injection facility. As such, the fault injection has been plugged
            into both the send and receive code paths. Regardless of method used
            the fault injection will operate on both egress and ingress packets.
         2. The type of fault injection - by packet or by opcode - is now controlled
            by changing the boolean value of the file "opcode_mode". When the value
            is set to True, fault injection is done by opcode. Otherwise, by
            packet.
         2. The masking ability has been removed in favor of a bitmap that holds
            opcodes of interest (one bit per opcode, a total of 256 bits). This
            works in tandem with the "opcode_mode" value. When the value of
            "opcode_mode" is False, this bitmap is ignored. When the value is
            True, the bitmap lists all opcodes to be considered for fault injection.
            By default, the bitmap is empty. When the user wants to filter by opcode,
            the user sets the corresponding bit in the bitmap by echo'ing the bit
            position into the 'opcodes' file. This gets around the issue that the set
            of opcodes does not lend itself to effective masks and allow for extremely
            fine-grained filtering by opcode.
         4. fault_packet and fault_opcode methods have been combined. Hence, there
            is only one debugfs directory controlling the entire operation of the
            fault injection machinery. This reduces the number of debugfs entries
            and provides a more unified user experience.
         5. A new control files - "direction" - is provided to allow the user to
            control the direction of packets, which are subject to fault injection.
         6. A new control file - "skip_usec" - is added that would allow the user
            to specify a "timeout" during which no fault injection will occur.
      
      In addition, the following bug fixes have been applied:
      
         1. The fault injection code has been split into its own header and source
            files. This was done to better organize the code and support conditional
            compilation without littering the code with #ifdef's.
         2. The method by which the TX PIO packets were being marked for drop
            conflicted with the way send contexts were being setup. As a result,
            the send context was repeatedly being reset.
         3. The fault injection only makes sense when the user can control it
            through the debugfs entries. However, a kernel configuration can
            enable fault injection but keep fault injection debugfs entries
            disabled. Therefore, it makes sense that the HFI fault injection
            code depends on both.
         4. Error suppression did not take into account the method by which PIO
            packets were being dropped. Therefore, even with error suppression
            turned on, errors would still be displayed to the screen. A larger
            enough packet drop percentage would case the kernel to crash because
            the driver would be stuck printing errors.
      Reviewed-by: default avatarDennis Dalessandro <dennis.dalessandro@intel.com>
      Reviewed-by: default avatarDon Hiatt <don.hiatt@intel.com>
      Reviewed-by: default avatarMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: default avatarMitko Haralanov <mitko.haralanov@intel.com>
      Signed-off-by: default avatarDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      a74d5307
    • Alex Estrin's avatar
      IB/{hfi1, qib}: Add handling of kernel restart · 8d3e7113
      Alex Estrin authored
      A warm restart will fail to unload the driver, leaving link state
      potentially flapping up to the point the BIOS resets the adapter.
      Correct the issue by hooking the shutdown pci method,
      which will bring port down.
      
      Cc: <stable@vger.kernel.org> # 4.9.x
      Reviewed-by: default avatarMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: default avatarAlex Estrin <alex.estrin@intel.com>
      Signed-off-by: default avatarDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      8d3e7113
    • Michael J. Ruhl's avatar
      IB/hfi1: Reorder incorrect send context disable · a93a0a31
      Michael J. Ruhl authored
      User send context integrity bits are cleared before the context is
      disabled.  If the send context is still processing data, any packets
      that need those integrity bits will cause an error and halt the send
      context.
      
      During the disable handling, the driver waits for the context to drain.
      If the context is halted, the driver will eventually timeout because
      the context won't drain and then incorrectly bounce the link.
      
      Reorder the bit clearing and the context disable.
      
      Examine the software state and send context status as well as the
      egress status to determine if a send context is in the halted state.
      
      Promote the check macros to static functions for consistency with the
      new check and to follow kernel style.
      
      Remove an unused define that refers to the egress timeout.
      
      Cc: <stable@vger.kernel.org> # 4.9.x
      Reviewed-by: default avatarMitko Haralanov <mitko.haralanov@intel.com>
      Reviewed-by: default avatarMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: default avatarMichael J. Ruhl <michael.j.ruhl@intel.com>
      Signed-off-by: default avatarDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      a93a0a31