1. 05 Aug, 2016 2 commits
  2. 17 Mar, 2016 2 commits
  3. 11 Jan, 2016 2 commits
  4. 08 Nov, 2015 5 commits
  5. 07 Sep, 2015 5 commits
    • Dave Jiang's avatar
      NTB: Use unique DMA channels for TX and RX · 569410ca
      Dave Jiang authored
      Allocate two DMA channels, one for TX operation and one for RX
      operation, instead of having one DMA channel for everything. This
      provides slightly better performance, and also will make error handling
      cleaner later on.
      Signed-off-by: default avatarDave Jiang <dave.jiang@intel.com>
      Signed-off-by: default avatarJon Mason <jdmason@kudzu.us>
      569410ca
    • Allen Hubbe's avatar
      NTB: Remove dma_sync_wait from ntb_async_rx · 905921e7
      Allen Hubbe authored
      The dma_sync_wait can hurt the performance of workloads mixed with both
      large and small frames.  Large frames will be copied using the dma
      engine.  Small frames will be copied by the cpu.  The dma_sync_wait
      prevents the cpu and dma engine copying in parallel.
      
      In the period where the cpu is copying, the dma engine is stopped.  The
      dma engine is not doing any useful work to copy large frames during that
      time, and the additional time to restart the dma engine for the next
      large frame.  This will decrease the throughput for the portion of a
      workload with large frames.
      
      In the period where the dma engine is copying, the cpu is held up
      waiting for dma to complete.  The small frames processing will be
      delayed until the dma is complete.  The RX frames are completed
      in-order, and the processing of small frames takes very little time, so
      dma_sync_wait may have an insignificant impact on the respose time of
      frames.  The more significant impact is to the system, because the delay
      in dma_sync_wait is implemented as busy non-blocking wait.  This can
      prevent the delayed core from doing any useful work, even if it could be
      processing work for other drivers, unrelated to transport RX processing.
      
      After applying the earlier patch to fix out-of-order RX acknoledgement,
      the dma_sync_wait is no longer necessary.  Remove it, so that cpu memcpy
      will proceed immediately for small frames, in parallel with ongoing dma
      for large frames.  Do not hold up the cpu from doing work while dma is
      in progress.  The prior fix will continue to ensure in-order completion
      of the RX frames to the upper layer, and in-order delivery of the RX
      acknoledgement.
      Signed-off-by: default avatarAllen Hubbe <Allen.Hubbe@emc.com>
      Signed-off-by: default avatarJon Mason <jdmason@kudzu.us>
      905921e7
    • Dave Jiang's avatar
      NTB: Clean up QP stats info · d98ef99e
      Dave Jiang authored
      Make QP stats info more readable for debugging purposes.  Also add an
      entry to indicate whether DMA is being used.
      Signed-off-by: default avatarDave Jiang <dave.jiang@intel.com>
      Signed-off-by: default avatarJon Mason <jdmason@kudzu.us>
      d98ef99e
    • Dave Jiang's avatar
      NTB: Make the transport list in order of discovery · 31510000
      Dave Jiang authored
      The list should be added from the bottom and not the top in order to
      ensure the transport is provided in the same order to clients as ntb
      devices are discovered.
      Signed-off-by: default avatarDave Jiang <dave.jiang@intel.com>
      Signed-off-by: default avatarJon Mason <jdmason@kudzu.us>
      31510000
    • Dave Jiang's avatar
      NTB: Add flow control to the ntb_netdev · e74bfeed
      Dave Jiang authored
      Right now if we push the NTB really hard, we start dropping packets due
      to not able to process the packets fast enough. We need to st:qop the
      upper layer from flooding us when that happens.
      
      A timer is necessary in order to restart the queue once the resource has
      been processed on the receive side. Due to the way NTB is setup, the
      resources on the tx side are tied to the processing of the rx side and
      there's no async way to know when the rx side has released those
      resources.
      Signed-off-by: default avatarDave Jiang <dave.jiang@intel.com>
      Signed-off-by: default avatarJon Mason <jdmason@kudzu.us>
      e74bfeed
  6. 09 Aug, 2015 6 commits
  7. 04 Jul, 2015 11 commits
  8. 02 Jul, 2015 1 commit
  9. 13 Sep, 2014 2 commits
  10. 07 Apr, 2014 2 commits
  11. 20 Nov, 2013 2 commits