<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/infiniband, branch v2.6.25</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers/infiniband?h=v2.6.25</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers/infiniband?h=v2.6.25'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2008-03-30T21:20:24Z</updated>
<entry>
<title>trivial endianness annotations: infiniband core</title>
<updated>2008-03-30T21:20:24Z</updated>
<author>
<name>Al Viro</name>
<email>viro@ftp.linux.org.uk</email>
</author>
<published>2008-03-29T03:10:28Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1b90c137cc2a0e9b813a8ae316827c493c664146'/>
<id>urn:sha1:1b90c137cc2a0e9b813a8ae316827c493c664146</id>
<content type='text'>
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>RDMA/cxgb3: Program hardware IRD with correct value</title>
<updated>2008-03-28T17:45:32Z</updated>
<author>
<name>Roland Dreier</name>
<email>rdreier@cisco.com</email>
</author>
<published>2008-03-28T17:28:17Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1f71f50342c6fe4fbdebe63b0fd196972a70e281'/>
<id>urn:sha1:1f71f50342c6fe4fbdebe63b0fd196972a70e281</id>
<content type='text'>
Because of a typo in iwch_accept_cr(), the cxgb3 connection handling
code programs the hardware IRD (incoming RDMA read queue depth) with
the value that is passed in for the ORD (outgoing RDMA read queue
depth).  In particular this means that if an application passes in IRD
&gt; 0 and ORD = 0 (which is a completely sane and valid thing to do for
an app that expects only incoming RDMA read requests), then the
hardware will end up programmed with IRD = 0 and the app will fail in
a mysterious way.

Fix this by using "ep-&gt;ird" instead of "ep-&gt;ord" in the intended place.

Signed-off-by: Roland Dreier &lt;rolandd@cisco.com&gt;
Acked-by: Steve Wise &lt;swise@opengridcomputing.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>RDMA/nes: Fix MSS calculation on RDMA path</title>
<updated>2008-03-21T20:59:28Z</updated>
<author>
<name>Chien Tung</name>
<email>ctung@neteffect.com</email>
</author>
<published>2008-03-21T00:55:30Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f2b2b59b93082d02ee5ec8fda4ed94f498551a47'/>
<id>urn:sha1:f2b2b59b93082d02ee5ec8fda4ed94f498551a47</id>
<content type='text'>
Fix the calculation of the MSS for RDMA connections: we need to
allow space in frames for a VLAN tag too.

Signed-off-by: Chien Tung &lt;ctung@neteffect.com&gt;
Signed-off-by: Glenn Streiff &lt;gstreiff@neteffect.com&gt;
Signed-off-by: Roland Dreier &lt;rolandd@cisco.com&gt;
</content>
</entry>
<entry>
<title>IPoIB: Allocate priv-&gt;tx_ring with vmalloc()</title>
<updated>2008-03-12T14:51:03Z</updated>
<author>
<name>Roland Dreier</name>
<email>rolandd@cisco.com</email>
</author>
<published>2008-03-12T14:51:03Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=10313cbb92206450b450e14f2b3f6ccde42d9a34'/>
<id>urn:sha1:10313cbb92206450b450e14f2b3f6ccde42d9a34</id>
<content type='text'>
Commit 7143740d ("IPoIB: Add send gather support") made struct
ipoib_tx_buf significantly larger, since the mapping member changed
from a single u64 to an array with MAX_SKB_FRAGS + 1 entries.  This
means that allocating tx_rings with kzalloc() may fail because there
is not enough contiguous memory for the new, much bigger size.  Fix
this regression by allocating the rings with vmalloc() instead.

Signed-off-by: Roland Dreier &lt;rolandd@cisco.com&gt;
</content>
</entry>
<entry>
<title>IPoIB/cm: Set tx_wr.num_sge in connected mode post_send()</title>
<updated>2008-03-12T01:35:20Z</updated>
<author>
<name>Roland Dreier</name>
<email>rolandd@cisco.com</email>
</author>
<published>2008-03-12T01:35:20Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=4200406b8fbbf309f4fffb339bd16c4553ae0c30'/>
<id>urn:sha1:4200406b8fbbf309f4fffb339bd16c4553ae0c30</id>
<content type='text'>
Commit 7143740d ("IPoIB: Add send gather support") made it possible
for tx_wr.num_sge to be != 1 -- this happens if send gather support is
enabled.  However, the code in the connected mode post_send() function
assumes the old invariant, namely that tx_wr.num_sge is always 1.  Fix
this by explicitly setting tx_wr.num_sge to 1 in the CM post_send().

Signed-off-by: Roland Dreier &lt;rolandd@cisco.com&gt;
</content>
</entry>
<entry>
<title>IPoIB: Don't drop multicast sends when they can be queued</title>
<updated>2008-03-11T21:12:03Z</updated>
<author>
<name>Or Gerlitz</name>
<email>ogerlitz@voltaire.com</email>
</author>
<published>2008-03-11T14:10:02Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b3e2749bf32f61e7beb259eb7cfb066d2ec6ad65'/>
<id>urn:sha1:b3e2749bf32f61e7beb259eb7cfb066d2ec6ad65</id>
<content type='text'>
When set_multicast_list() is called the multicast task is restarted
and the IPOIB_MCAST_STARTED bit is cleared.  As a result for some
window of time, multicast packets are not transmitted nor queued but
rather dropped by ipoib_mcast_send().  These dropped packets are
painful in two cases:

 - bonding fail-over which both calls set_multicast_list() on the new
   active slave and sends Gratuitous ARP through that slave.

 - IP_DROP_MEMBERSHIP code which both calls set_multicast_list() on the
   device and issues IGMP leave.

In both these cases, depending on the scheduling of the IPoIB
multicast task, the packets would be dropped.  As a result, in the
bonding case, the failover would not be detected by the peers until
their neighbour is renewed the neighbour (which takes a few tens of
seconds).  In the IGMP case, the IP router doesn't get an IGMP leave
and would only learn on that from further probes on the group (also a
delay of at least a few tens of seconds).

Fix this by allowing transmission (or queuing) depending on the
IPOIB_FLAG_OPER_UP flag instead of the IPOIB_MCAST_STARTED flag.

Signed-off-by: Olga Shern &lt;olgas@voltaire.com&gt;
Signed-off-by: Or Gerlitz &lt;ogerlitz@voltaire.com&gt;
Signed-off-by: Roland Dreier &lt;rolandd@cisco.com&gt;
</content>
</entry>
<entry>
<title>IB/ipath: Reset the retry counter for RDMA_READ_RESPONSE_MIDDLE packets</title>
<updated>2008-03-11T21:04:35Z</updated>
<author>
<name>Patrick Marchand Latifi</name>
<email>patrick.latifi@qlogic.com</email>
</author>
<published>2008-02-21T03:08:10Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=450bb3875f5f5ab3679823c941d6045d16967370'/>
<id>urn:sha1:450bb3875f5f5ab3679823c941d6045d16967370</id>
<content type='text'>
Reset the retry counter when we get a good RDMA_READ_RESPONSE_MIDDLE
packet.  This fix will prevent the requester from reporting a retry
exceeded error too early.

Signed-off-by: Patrick Marchand Latifi &lt;patrick.latifi@qlogic.com&gt;
</content>
</entry>
<entry>
<title>IB/ipath: Fix error completion put on send CQ instead of recv CQ</title>
<updated>2008-03-11T21:03:54Z</updated>
<author>
<name>Patrick Marchand Latifi</name>
<email>patrick.latifi@qlogic.com</email>
</author>
<published>2008-01-31T08:24:37Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2a049e514b890c8b70b965bbd9f4e3c963af69c9'/>
<id>urn:sha1:2a049e514b890c8b70b965bbd9f4e3c963af69c9</id>
<content type='text'>
A work completion entry could be placed on the wrong completion
queue when an RC QP is placed in the error state.

Signed-off-by: Patrick Marchand Latifi &lt;patrick.latifi@qlogic.com&gt;
Acked-by: Ralph Campbell &lt;ralph.campbell@qlogic.com&gt;
Signed-off-by: Roland Dreier &lt;rolandd@cisco.com&gt;
</content>
</entry>
<entry>
<title>IB/ipath: Fix RC QP initialization</title>
<updated>2008-03-11T21:02:32Z</updated>
<author>
<name>Patrick Marchand Latifi</name>
<email>patrick.latifi@qlogic.com</email>
</author>
<published>2008-01-19T04:10:48Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=4cd5060cf7c2207c31e2e368f8a6343355362e51'/>
<id>urn:sha1:4cd5060cf7c2207c31e2e368f8a6343355362e51</id>
<content type='text'>
This patch fixes the initialization of RC QPs, since we would rely on
the queue pair type (ibqp-&gt;qp_type) being set, but this field is only
initialized when we return from ipath_create_qp (it is initialized by
the user-level verbs library).

The fix is to not depend on this field to initialize the send and
the receive state of the RC QP.

Signed-off-by: Patrick Marchand Latifi &lt;patrick.latifi@qlogic.com&gt;
Signed-off-by: Roland Dreier &lt;rolandd@cisco.com&gt;
</content>
</entry>
<entry>
<title>IB/ipath: Fix potentially wrong RNR retry counter returned in ipath_query_qp()</title>
<updated>2008-03-11T21:01:14Z</updated>
<author>
<name>Patrick Marchand Latifi</name>
<email>patrick.latifi@qlogic.com</email>
</author>
<published>2008-01-08T07:43:04Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=87d5aed85b2d79e4075ad2ca1449e9b98f657a09'/>
<id>urn:sha1:87d5aed85b2d79e4075ad2ca1449e9b98f657a09</id>
<content type='text'>
There can be a case where the requester's rnr retry counter
(s_rnr_retry) is less than the number of rnr retries allowed per QP
(s_rnr_retry_cnt).  This can happen if the s_rnr_retry counter is being
decremented and an ipath_query_qp call is issued during that time frame.
The fix is to always return the number of rnr retries allowed per QP
instead of the requester's rnr counter.

Found by code review.

Signed-off-by: Patrick Marchand Latifi &lt;patrick.latifi@qlogic.com&gt;
Acked-by: Ralph Campbell &lt;ralph.campbell@qlogic.com&gt;
Signed-off-by: Roland Dreier &lt;rolandd@cisco.com&gt;
</content>
</entry>
</feed>
