Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 13 5月, 2008 1 次提交
  3. 07 5月, 2008 1 次提交
  5. 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
  7. 19 4月, 2008 1 次提交
  9. 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
  11. 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
  13. 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
  15. 04 3月, 2008 1 次提交
  17. 12 2月, 2008 1 次提交
  19. 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
  21. 06 2月, 2008 1 次提交
  23. 03 2月, 2008 1 次提交
  25. 29 1月, 2008 15 次提交
  27. 08 12月, 2007 1 次提交
  29. 24 10月, 2007 1 次提交
  31. 20 10月, 2007 1 次提交
  33. 11 10月, 2007 9 次提交