1. 09 10月, 2008 8 次提交
  2. 25 9月, 2008 2 次提交
  3. 22 9月, 2008 1 次提交
  4. 30 7月, 2008 1 次提交
  5. 27 7月, 2008 1 次提交
    • F
      dma-mapping: add the device argument to dma_mapping_error() · 8d8bb39b
      FUJITA Tomonori 提交于
      Add per-device dma_mapping_ops support for CONFIG_X86_64 as POWER
      architecture does:
      
      This enables us to cleanly fix the Calgary IOMMU issue that some devices
      are not behind the IOMMU (http://lkml.org/lkml/2008/5/8/423).
      
      I think that per-device dma_mapping_ops support would be also helpful for
      KVM people to support PCI passthrough but Andi thinks that this makes it
      difficult to support the PCI passthrough (see the above thread).  So I
      CC'ed this to KVM camp.  Comments are appreciated.
      
      A pointer to dma_mapping_ops to struct dev_archdata is added.  If the
      pointer is non NULL, DMA operations in asm/dma-mapping.h use it.  If it's
      NULL, the system-wide dma_ops pointer is used as before.
      
      If it's useful for KVM people, I plan to implement a mechanism to register
      a hook called when a new pci (or dma capable) device is created (it works
      with hot plugging).  It enables IOMMUs to set up an appropriate
      dma_mapping_ops per device.
      
      The major obstacle is that dma_mapping_error doesn't take a pointer to the
      device unlike other DMA operations.  So x86 can't have dma_mapping_ops per
      device.  Note all the POWER IOMMUs use the same dma_mapping_error function
      so this is not a problem for POWER but x86 IOMMUs use different
      dma_mapping_error functions.
      
      The first patch adds the device argument to dma_mapping_error.  The patch
      is trivial but large since it touches lots of drivers and dma-mapping.h in
      all the architecture.
      
      This patch:
      
      dma_mapping_error() doesn't take a pointer to the device unlike other DMA
      operations.  So we can't have dma_mapping_ops per device.
      
      Note that POWER already has dma_mapping_ops per device but all the POWER
      IOMMUs use the same dma_mapping_error function.  x86 IOMMUs use device
      argument.
      
      [akpm@linux-foundation.org: fix sge]
      [akpm@linux-foundation.org: fix svc_rdma]
      [akpm@linux-foundation.org: build fix]
      [akpm@linux-foundation.org: fix bnx2x]
      [akpm@linux-foundation.org: fix s2io]
      [akpm@linux-foundation.org: fix pasemi_mac]
      [akpm@linux-foundation.org: fix sdhci]
      [akpm@linux-foundation.org: build fix]
      [akpm@linux-foundation.org: fix sparc]
      [akpm@linux-foundation.org: fix ibmvscsi]
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Muli Ben-Yehuda <muli@il.ibm.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Avi Kivity <avi@qumranet.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8d8bb39b
  6. 15 7月, 2008 2 次提交
    • S
      RDMA/cxgb3: Fixes for zero STag · 4ab928f6
      Steve Wise 提交于
      Handling the zero STag in receive work request requires some extra
      logic in the driver:
      
       - Only set the QP_PRIV bit for kernel mode QPs.
      
      - Add a zero STag build function for recv wrs. The uP needs a PBL
        allocated and passed down in the recv WR so it can construct a HW
        PBL for the zero STag S/G entries.  Note: we need to place a few
        restrictions on zero STag usage because of this:
      
        1) all SGEs in a recv WR must either be zero STag or not.  No mixing.
      
        2) an individual SGE length cannot exceed 128MB for a zero-stag SGE.
           This should be OK since it's not really practical to allocate
           such a large chunk of pinned contiguous DMA mapped memory.
      
      - Add an optimized non-zero-STag recv wr format for kernel users.
        This is needed to optimize both zero and non-zero STag cracking in
        the recv path for kernel users.
      
       - Remove the iwch_ prefix from the static build functions.
      
       - Bump required FW version.
      Signed-off-by: NSteve Wise <swise@opengridcomputing.com>
      4ab928f6
    • S
      RDMA/cxgb3: Add support for protocol statistics · 14cc180f
      Steve Wise 提交于
      - Add a new rdma ctl command called RDMA_GET_MIB to the cxgb3 low
        level driver to obtain the protocol mib from the rnic hardware.
      
      - Add new iw_cxgb3 provider method to get the MIB from the low level
        driver.
      Signed-off-by: NSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      14cc180f
  7. 11 7月, 2008 1 次提交
  8. 10 7月, 2008 1 次提交
  9. 08 7月, 2008 1 次提交
  10. 25 6月, 2008 1 次提交
  11. 22 5月, 2008 3 次提交
  12. 13 5月, 2008 2 次提交
  13. 07 5月, 2008 1 次提交
  14. 30 4月, 2008 1 次提交
    • S
      RDMA/cxgb3: Support peer-2-peer connection setup · f8b0dfd1
      Steve Wise 提交于
      Open MPI, Intel MPI and other applications don't respect the iWARP
      requirement that the client (active) side of the connection send the
      first RDMA message.  This class of application connection setup is
      called peer-to-peer.  Typically once the connection is setup, _both_
      sides want to send data.
      
      This patch enables supporting peer-to-peer over the chelsio RNIC by
      enforcing this iWARP requirement in the driver itself as part of RDMA
      connection setup.
      
      Connection setup is extended, when the peer2peer module option is 1,
      such that the MPA initiator will send a 0B Read (the RTR) just after
      connection setup.  The MPA responder will suspend SQ processing until
      the RTR message is received and reply-to.
      
      In the longer term, this will be handled in a standardized way by
      enhancing the MPA negotiation so peers can indicate whether they
      want/need the RTR and what type of RTR (0B read, 0B write, or 0B send)
      should be sent.  This will be done by standardizing a few bits of the
      private data in order to negotiate all this.  However this patch
      enables peer-to-peer applications now and allows most of the required
      firmware and driver changes to be done and tested now.
      
      Design:
      
       - Add a module option, peer2peer, to enable this mode.
      
       - New firmware support for peer-to-peer mode:
      
      	- a new bit in the rdma_init WR to tell it to do peer-2-peer
      	  and what form of RTR message to send or expect.
      
      	- process _all_ preposted recvs before moving the connection
      	  into rdma mode.
      
      	- passive side: defer completing the rdma_init WR until all
      	  pre-posted recvs are processed.  Suspend SQ processing until
      	  the RTR is received.
      
      	- active side: expect and process the 0B read WR on offload TX
      	  queue. Defer completing the rdma_init WR until all
      	  pre-posted recvs are processed.  Suspend SQ processing until
      	  the 0B read WR is processed from the offload TX queue.
      
       - If peer2peer is set, driver posts 0B read request on offload TX
         queue just after posting the rdma_init WR to the offload TX queue.
      
       - Add CQ poll logic to ignore unsolicitied read responses.
      Signed-off-by: NSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      f8b0dfd1
  15. 19 4月, 2008 1 次提交
  16. 18 4月, 2008 1 次提交
    • D
      cxgb3: Fix __must_check warning with dev_dbg. · d96a51f6
      Dan Noe 提交于
      Fix the warning:
      drivers/net/cxgb3/cxgb3_main.c: In function ‘offload_open’:
      drivers/net/cxgb3/cxgb3_main.c:936: warning: ignoring return value of
       ‘sysfs_create_group’, declared with attribute warn_unused_result
      
      Now the return value is checked; if sysfs_create_group() returns failure,
      a warning is printed using dev_dbg, and the code continues as before.  Use
      of dev_dbg ensures printk is not needlessly included unless desired for
      debugging.
      Signed-off-by: NDan Noe <dpn@isomerica.net>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      d96a51f6
  17. 26 3月, 2008 2 次提交
    • A
      annotate cxgb3 (ab)uses of skb->priority/skb->csum · fa3a6cb4
      Al Viro 提交于
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      fa3a6cb4
    • R
      cxgb3: Fix lockdep problems with sge.reg_lock · b1186dee
      Roland Dreier 提交于
      Using iWARP with a Chelsio T3 NIC generates the following lockdep warning:
      
          =================================
          [ INFO: inconsistent lock state ]
          2.6.25-rc6 #50
          ---------------------------------
          inconsistent {softirq-on-W} -> {in-softirq-W} usage.
          swapper/0 [HC0[0]:SC1[1]:HE0:SE0] takes:
           (&adap->sge.reg_lock){-+..}, at: [<ffffffff880e5ee2>] cxgb_offload_ctl+0x3af/0x507 [cxgb3]
      
      The problem is that reg_lock is used with plain spin_lock() in
      drivers/net/cxgb3/sge.c but is used with spin_lock_irqsave() in
      drivers/net/cxgb3/cxgb3_offload.c.  This is technically a false
      positive, since the uses in sge.c are only in the initialization and
      cleanup paths and cannot overlap with any use in interrupt context.
      
      The best fix is probably just to use spin_lock_irq() with reg_lock in
      sge.c.  Even though it's not strictly required for correctness, it
      avoids triggering lockdep and the extra overhead of disabling
      interrupts is not important at all in the initialization and cleanup
      slow paths.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      b1186dee
  18. 17 3月, 2008 1 次提交
    • D
      cxgb3: Fix transmit queue stop mechanism · cd7e9034
      Divy Le Ray 提交于
      The last change in the Tx queue stop mechanism opens a window
      where the Tx queue might be stopped after pending credits
      returned.
      
      Tx credits are returned via a control message generated by the HW.
      It returns tx credits on demand, triggered by a completion bit
      set in selective transmit packet headers.
      
      The current code can lead to the Tx queue stopped
      with all pending credits returned, and the current frame
      not triggering a credit return. The Tx queue will then never be
      awaken.
      
      The driver could alternatively request a completion for packets
      that stop the queue. It's however safer at this point to go back
      to the pre-existing behaviour.
      Signed-off-by: NDivy Le Ray <divy@chelsio.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      cd7e9034
  19. 04 3月, 2008 1 次提交
  20. 12 2月, 2008 1 次提交
  21. 11 2月, 2008 1 次提交
    • K
      Optimize cxgb3 xmit path (a bit) · a8cc21f6
      Krishna Kumar 提交于
      	1. Add common code for stopping queue.
      	2. No need to call netif_stop_queue followed by netif_wake_queue (and
      	   infact a netif_start_queue could have been used instead), instead
      	   call stop_queue if required, and remove code under USE_GTS macro.
      	3. There is no need to check for netif_queue_stopped, as the network
      	   core guarantees that for us (I am sure every driver could remove
      	   that check, eg e1000 - I have tested that path a few billion times
      	   with about a few hundred thousand qstops but the condition never
      	   hit even once).
      Signed-off-by: NKrishna Kumar <krkumar2@in.ibm.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      a8cc21f6
  22. 06 2月, 2008 1 次提交
  23. 03 2月, 2008 1 次提交
  24. 29 1月, 2008 4 次提交