[ewg] OFED 1.3.1 RC1 release is available
Hi, OFED 1.3.1 RC1 release is available on http://www.openfabrics.org/downloads/OFED/ofed-1.3.1/OFED-1.3.1-rc1.tgz To get BUILD_ID run ofed_info Please report any issues in Bugzilla https://bugs.openfabrics.org/ The RC2 release is expected on May 20 Release information: Linux Operating Systems: - RedHat EL4 up4: 2.6.9-42.ELsmp - RedHat EL4 up5: 2.6.9-55.ELsmp - RedHat EL4 up6: 2.6.9-67.ELsmp - RedHat EL5: 2.6.18-8.el5 - RedHat EL5 up1: 2.6.18-53.el5 - Fedora C6:2.6.18-8.fc6 - SLES10: 2.6.16.21-0.8-smp - SLES10 SP1: 2.6.16.46-0.12-smp - SLES10 SP1 up1: 2.6.16.53-0.16-smp - OpenSuSE 10.3:2.6.22-*-* - kernel.org: 2.6.23 and 2.6.24 Systems: * x86_64 * x86 * ia64 * ppc64 Main Changes from OFED-1.3: * MPI packages update: * mvapich-1.0.1-2434 * mvapich2-1.0.3-1 * openmpi-1.2.6-1 * Updated libraries: * dapl-v1 1.2.6 * dapl-v2 2.0.8 * libcxgb3 1.2.0 * librdmacm 1.0.7 I * ULPs changes: * IB Bonding: ib-bonding-0.9.0-24 * IPoIB bug fixes * RDS fixes for RDMA API * SRP failover * Updated low level drivers: * nes * mlx4 * cxgb3 * ehca Note: In the attached tgz file you can find git-log of all changes. Vlad Tziporet ofed-1.3-1.3.1-rc1.diff.tgz Description: Binary data ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH] Request For Comments:
- always do peer2peer and don't let the app choose. This forces the overhead of p2p mode on all apps, but preserves the API. How bad is the overhead? - R. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH] Request For Comments:
Roland Dreier wrote: - always do peer2peer and don't let the app choose. This forces the overhead of p2p mode on all apps, but preserves the API. How bad is the overhead? - R. The client side must send a Ready To Receive message. This will be negotiated via the MPA exchange and the resulting RTR message may be a 0B read + read response, 0B write, or a 0B send. For chelsio, the 0B write couldn't be used, and the 0B read was the least impact on the driver code, so we used that. For nes, they currently use a 0B write. Also, there are some caveats if you turn this on: 1) private data is used to negotiate the type of RTR message and if its needed. This is more of a global module option I think, since it will break interoperability with iwarp. Prolly will bump the MPA version number if this option is on too. 2) if the RTR message fails, it can generate a CQE that is unexpected. 3) if using SEND, then a recv completion is always generated. Steve. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] OFED-1.4 makedist failure?
I made a fresh clone of git://git.openfabrics.org/ofed_1_4/linux-2.6.git and tried ofed_scripts/ofed_makedist.sh from the top level directory and got: [EMAIL PROTECTED]:~/scm/linux-2.6$ ofed_scripts/ofed_makedist.sh git clone -q -s -n --reference /home/vlad/scm/ofed_kernel.git /home/ralphc/scm/linux-2.6 /tmp/build-ofed_kernel-oPkNjv/ofed_kernel-2.6.11 Initialized empty Git repository in /tmp/build-ofed_kernel-oPkNjv/ofed_kernel-2.6.11/.git/ pushd /tmp/build-ofed_kernel-oPkNjv/ofed_kernel-2.6.11 /tmp/build-ofed_kernel-oPkNjv/ofed_kernel-2.6.11 ~/scm/linux-2.6 /home/ralphc/scm/linux-2.6/ofed_scripts/ofed_checkout.sh 6002e5e4a9ee0661ca6a5bc9feb191bef3b52e66 6002e5e4a9ee0661ca6a5bc9feb191bef3b52e66 /tmp/build-ofed_kernel-oPkNjv/ofed_kernel-2.6.11.log /home/ralphc/scm/linux-2.6/ofed_scripts/ofed_patch.sh --with-backport=2.6.11 /tmp/build-ofed_kernel-oPkNjv/ofed_kernel-2.6.11.log Failed executing /home/ralphc/scm/linux-2.6/ofed_scripts/ofed_patch.sh --with-backport=2.6.11 /tmp/build-ofed_kernel-oPkNjv/ofed_kernel-2.6.11.log Hunk #5 succeeded at 673 (offset -17 lines). Hunk #6 succeeded at 683 (offset -17 lines). Hunk #7 succeeded at 720 (offset -17 lines). patching file drivers/infiniband/ulp/ipoib/ipoib_multicast.c Hunk #3 succeeded at 653 with fuzz 1 (offset 1 line). Hunk #4 succeeded at 668 (offset 1 line). Hunk #5 succeeded at 683 (offset 1 line). Patch ipoib_0100_to_2.6.21.patch does not apply (enforce with -f) Failed executing /usr/bin/quiltBuild failed in /tmp/build-ofed_kernel-oPkNjv See log file /tmp/build-ofed_kernel-oPkNjv/ofed_kernel-2.6.11.log Is this a known problem or am I doing something wrong? ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] Re: [PATCH] Request For Comments:
Caitlin Bestler wrote: On Tue, May 6, 2008 at 11:32 AM, Steve Wise [EMAIL PROTECTED] wrote: Roland Dreier wrote: - always do peer2peer and don't let the app choose. This forces the overhead of p2p mode on all apps, but preserves the API. How bad is the overhead? - R. The client side must send a Ready To Receive message. This will be negotiated via the MPA exchange and the resulting RTR message may be a 0B read + read response, 0B write, or a 0B send. For chelsio, the 0B write couldn't be used, and the 0B read was the least impact on the driver code, so we used that. For nes, they currently use a 0B write. Also, there are some caveats if you turn this on: 1) private data is used to negotiate the type of RTR message and if its needed. This is more of a global module option I think, since it will break interoperability with iwarp. Prolly will bump the MPA version number if this option is on too. 2) if the RTR message fails, it can generate a CQE that is unexpected. 3) if using SEND, then a recv completion is always generated. Steve. Keep in mind that even if it is a zero byte RDMA Write, it is still a distinct packet that needs TCP handling, will occupy a buffer in various switch queues, etc. So while it can be about as innocuous as any TCP segment can be, it is still an excess packet if it did not need to be sent. The overwhelming majority of applications use a client/server model rather than peer2peer. For them this is an excess wire packet, so I think that would make it excessive overhead. Secondly, the applications that need this feature will generally know that they need it. Developers of MPI and other peer-2-peer applications tend to know advanced networking a bit more than typical app developers. So keeping the default to match the client/server model makes sense. What are the overwhelming majority of user mode rdma applications that don't assume a peer2peer model? Steve. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
