On 12/16/2009 6:39 PM, Moni Shoua wrote:
Limitations:
- SLES10 SP3 on IA64 is not supported yet
In what way is it unsupported?
Our QA say that OFED-1.5 can be compiled on this platform.
OK - so it is supported
Tziporet
--
To unsubscribe from this list: send the line
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
As is done in ib_mthca and libmthca (per the ConnectX PRM), SRQ WQEs should
have their scatter
entries initialized to the invalid lkey when the SRQ is created. This entry is
the overflow indicator when the received packet is too large for the WQE s/g
buffer list.
Following are patches for
As in libmthca, need to initialize SRQ WQE scatter entries to the
invalid lkey at work queue creation time.
Signed-off-by: Jack Morgenstein ja...@dev.mellanox.co.il
diff --git a/src/srq.c b/src/srq.c
index ba2ceb9..f1d1240 100644
--- a/src/srq.c
+++ b/src/srq.c
@@ -128,6 +128,7 @@ int
The ipath driver, which I am more familiar with, replicated the transport
for RC, UC and UD which also caused some code duplication. We tried to
combine them all together in rxe.
Bob Pearson
-Original Message-
From: Roland Dreier [mailto:rdre...@cisco.com]
Sent: Wednesday, December 16,
Adds documentation to the libsrp source code.
Signed-off-by: Bart Van Assche bart.vanass...@gmail.com
Cc: James E.J. Bottomley james.bottom...@suse.de
Cc: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
Acked-by: Randy Dunlap randy.dun...@oracle.com
This is the third version of this patch.
Yes, but later. For now it is still being actively developed and is changing
a lot. Once it settles down we plan to convert to patches and push up
stream.
I think you would probably be better off developing the kernel driver as
a branch in an up-to-date kernel tree, and then worrying about
I agree about the polynomial. That would have been nice. As currently
proposed the embedding of the IB transport in Ethernet frames preserves the
IB ICRC as part of the transport and trades the VCRC for Ethernet's CRC32
over the whole frame. This means that the packet is effectively covered by
We have thought that we could try CRC32C first and if that works then use
that, otherwise fall back to CRC32 which would allow rxe to use CRC32C when
talking to itself and get a speedup on new Intel CPUs.
How would you negotiate that? Is this being worked in the definition of
the IBoE
On Thu, Dec 17, 2009 at 03:43:56PM -0600, Robert Pearson wrote:
I agree about the polynomial. That would have been nice. As currently
proposed the embedding of the IB transport in Ethernet frames preserves the
IB ICRC as part of the transport and trades the VCRC for Ethernet's CRC32
over the
Forgot to reply to one other point. For the most part we have been
developing in vanilla recent kernel.org trees when we are testing rxe-rxe.
To talk to ConnectX we need to use the OFED-rdmaoe environment and then we
have to play with symvers. If support for ConnectX-en with rdmaoe were
upstream
Oops. I should have said ICRC not VCRC. There is no VCRC for rdmaoe.
The ICRC is, however, computed exactly the same as for an IB packet. It is
bit for bit identical.
-Original Message-
From: Robert Pearson [mailto:rpear...@systemfabricworks.com]
Sent: Thursday, December 17, 2009 5:00 PM
On Thu, Dec 17, 2009 at 05:00:26PM -0600, Robert Pearson wrote:
Of course we need to interoperate with ConnectX-en and it, as far as I know,
only knows how to compute the VCRC as though the packet was going to get
sent to IB including a phantom 12 byte LRH that is filled with 1's without
any
Of course we need to interoperate with ConnectX-en and it, as far as I know,
only knows how to compute the VCRC as though the packet was going to get
sent to IB including a phantom 12 byte LRH that is filled with 1's without
any way to turn it off. It is also a requirement that UD work
The ICRC isn't even necessary from a technical sense for DCE. The
underlying reasons for the ICRC/VCRC split are not really present for
ethernet. Considering RDMAoE isn't interoperable with existing IB anyhow
and DCE can't do routing, the best course would be to just get rid of
it
On Wed, 16 Dec 2009 08:29:43 -0500
Hal Rosenstock hal.rosenst...@gmail.com wrote:
On Tue, Dec 15, 2009 at 9:55 PM, Ira Weiny wei...@llnl.gov wrote:
[snip]
diff --git a/opensm/opensm/osm_sa_path_record.c
b/opensm/opensm/osm_sa_path_record.c
index be0cd71..1fa83a1 100644
---
16 matches
Mail list logo
