[ewg] OFED backport patch error
FYI, I took the 1.5.3rc4 and attempted to ofed_patch for each of the supported backports. For the 2.6.18-chaos backport, the following failed to apply: kernel_patches/backport/2.6.18-chaos/core_4_show_res_to_xxx.patch^M patching file drivers/infiniband/core/uverbs_main.c^M Hunk #1 FAILED at 870.^M Hunk #2 FAILED at 935.^M 2 out of 2 hunks FAILED -- saving rejects to file drivers/infiniband/core/uverbs _main.c.rej^M I went back and tried it with 1.5.3rc3 and observed the same error. I do not have a 2.6.18-chaos system handy, so I can't verify if this failure of this backport is important to operation or builds for that kernel. Todd Rimmer Chief Architect QLogic Network Systems Group Voice: 610-233-4852 Fax: 610-233-4777 todd.rim...@qlogic.com www.QLogic.com This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] OFED 1.5.2rc4 fails to build on RHEL4 Update 8 x86_64
I tried an install.pl --all on this distro. The ibacm module fails to build with undefined references to __sync_fetch_and_add and __sync_fetch_and_sub. I see these exist on newer distros, but they are not available on RHEL4. ibacm is using this in its linux/osd.h file to define atomic_inc and atomic_dec. An alternative might be to use /usr/include/asm/atomic.h as this has atomic_inc and atomic_dec macros already defined. I would also be more portable. Todd Rimmer Chief Architect QLogic Network Systems Group Voice: 610-233-4852 Fax: 610-233-4777 todd.rim...@qlogic.com www.QLogic.com ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] OFED 1.5.2rc4 fails to build on RHEL4 Update 8 x86_64
On my RHEL4 system, rpm -q --whatprovides /usr/include/asm/atomic.h Indicates: glibc-kernheaders-2.4-9.1.103.EL Todd Rimmer Chief Architect QLogic Network Systems Group Voice: 610-233-4852 Fax: 610-233-4777 todd.rim...@qlogic.com www.QLogic.com -Original Message- From: Hefty, Sean [mailto:sean.he...@intel.com] Sent: Wednesday, August 18, 2010 4:16 PM To: Todd Rimmer Cc: OpenFabrics EWG Subject: RE: OFED 1.5.2rc4 fails to build on RHEL4 Update 8 x86_64 An alternative might be to use /usr/include/asm/atomic.h as this has atomic_inc and atomic_dec macros already defined. I would also be more portable. This file doesn't exist on my systems. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] libibumad.so version bump in OFED 1.5.2
Is there a way to accomplish this feature without an ABI change? Or should ABI altering features be only included in Major releases (such as OFED 1.6?) I urged about ABI change on the list when this patch was posted. And I don't think that we can change the version back. Since 1.5.2 is not yet GA, we always have the option of altering this patch and moving the version back. It sounds like you too were concerned about this when the change went in, I suspect those on the list missed the ramifications to end users and ISVs of ABI changes during maintenance releases. A situation like this will leave many ISVs unable to support OFED 1.5.2. We've already seen that situation with OFED 1.4 - 1.5. The various API and ABI changes impacted many ISVs, so there are still some ISVs which are stuck on OFED 1.4 and have not yet released OFED 1.5 support. This of course is causing issues for customers which need OFED 1.5 features (such as newer kernel levels) but require a given ISV's software. Let's not repeat that same mistake for OFED 1.5.1 - 1.5.2. In contrast, other aspects of linux provide forward migration. For example I can generally build a binary on RHEL4 and run it on RHEL5. I can certainly build files on RHEL5.0 and run them on RHEL5.5. Heck, I've got quite a few tools whose binaries were built on even earlier redhat versions and still work fine on RHEL5.5. OFED applications should be no different. Todd Rimmer Chief Architect QLogic Network Systems Group Voice: 610-233-4852 Fax: 610-233-4777 todd.rim...@qlogic.com www.QLogic.com -Original Message- From: Sasha Khapyorsky [mailto:sashakv...@gmail.com] On Behalf Of Sasha Khapyorsky Sent: Tuesday, July 13, 2010 11:34 AM To: Todd Rimmer Cc: e...@openfabrics.org; Yevgeny Kliteynik; Tziporet Koren Subject: Re: libibumad.so version bump in OFED 1.5.2 On 12:58 Wed 07 Jul , Todd Rimmer wrote: Is there a way to accomplish this feature without an ABI change? Or should ABI altering features be only included in Major releases (such as OFED 1.6?) I urged about ABI change on the list when this patch was posted. And I don't think that we can change the version back. Keep in mind, that ABI changes mean that 3rd parties must rebuild and re-release their applications. While this isn't so bad for OFED itself and IB vendors, it's a major issue for other 3rd party apps. Introducing a ABI change in a maintenance release just makes things that much more confusing. One alternative would be for OFED 1.5.2 to include both the .2 and .3 versions of the library. We discussed such option - to have a package compat-libs or so, but as far as I can remember no one wanted to take responsibility to maintain this. Another alternative would be to design the structures so there is room for expansion or pointers to opaque datatypes for fields only used by the library. Currently it would mean API redesign and more version changes. Sasha Todd Rimmer Chief Architect QLogic Network Systems Group Voice: 610-233-4852 Fax: 610-233-4777 todd.rim...@qlogic.com www.QLogic.com -Original Message- From: Sasha Khapyorsky [mailto:sashakv...@gmail.com] On Behalf Of Sasha Khapyorsky Sent: Wednesday, July 07, 2010 9:34 AM To: Todd Rimmer Cc: e...@openfabrics.org Subject: Re: libibumad.so version bump in OFED 1.5.2 Hi Todd, On 06:48 Tue 06 Jul , Todd Rimmer wrote: I recently discovered that 3rd party applications built for OFED 1.5 will not run on OFED 1.5.2rc2. The issue I found was that libibumad had changed from version 2 to version 3. Can you provide insight as to why this change was made? In reviewing the source code and change logs there do not seem to be any changes which would impact the application API nor application ABI. I diffed the code and the main change seems to be: diff -r --exclude CVS ./src/src/umad.c-orig ./src/src/umad.c 161a162,166 if (sys_read_string(port_dir, SYS_PORT_LINK_LAYER, port-link_layer, UMAD_CA_NAME_LEN) 0) /* assume IB by default */ sprintf(port-link_layer, IB); The above change might imply an update to an rpm dependency on ib- kernel versions, but should not result in a new library version. If the library version remained at 2, then applications built for OFED 1.5 would also run on OFED 1.5.2rc2 without recompile. This is not an only change. The whole commit is: commit 99d0901f3702e22c178352524af18ec567781d51 Author: Yevgeny Kliteynik klit...@dev.mellanox.co.il Date: Tue Mar 9 12:39:40 2010 +0200 libibumad: added link_layer for RoCEE support and updated umad version Added link_layer field to umad_port_t. The field is implemented as char[]. If the relevant file doesn't exist in sysfs, the link layer is IB. Otherwise
Re: [ewg] libibumad.so version bump in OFED 1.5.2
Is there a way to accomplish this feature without an ABI change? Or should ABI
altering features be only included in Major releases (such as OFED 1.6?)
Keep in mind, that ABI changes mean that 3rd parties must rebuild and
re-release their applications. While this isn't so bad for OFED itself and IB
vendors, it's a major issue for other 3rd party apps. Introducing a ABI change
in a maintenance release just makes things that much more confusing.
One alternative would be for OFED 1.5.2 to include both the .2 and .3 versions
of the library.
Another alternative would be to design the structures so there is room for
expansion or pointers to opaque datatypes for fields only used by the library.
Todd Rimmer
Chief Architect
QLogic Network Systems Group
Voice: 610-233-4852 Fax: 610-233-4777
todd.rim...@qlogic.com www.QLogic.com
-Original Message-
From: Sasha Khapyorsky [mailto:sashakv...@gmail.com] On Behalf Of Sasha
Khapyorsky
Sent: Wednesday, July 07, 2010 9:34 AM
To: Todd Rimmer
Cc: e...@openfabrics.org
Subject: Re: libibumad.so version bump in OFED 1.5.2
Hi Todd,
On 06:48 Tue 06 Jul , Todd Rimmer wrote:
I recently discovered that 3rd party applications built for OFED 1.5
will not run on OFED 1.5.2rc2.
The issue I found was that libibumad had changed from version 2 to
version 3. Can you provide insight as to why this change was made?
In reviewing the source code and change logs there do not seem to be
any changes which would impact the application API nor application ABI.
I diffed the code and the main change seems to be:
diff -r --exclude CVS ./src/src/umad.c-orig ./src/src/umad.c
161a162,166
if (sys_read_string(port_dir, SYS_PORT_LINK_LAYER,
port-link_layer, UMAD_CA_NAME_LEN) 0)
/* assume IB by default */
sprintf(port-link_layer, IB);
The above change might imply an update to an rpm dependency on ib-
kernel versions, but should not result in a new library version. If
the library version remained at 2, then applications built for OFED 1.5
would also run on OFED 1.5.2rc2 without recompile.
This is not an only change. The whole commit is:
commit 99d0901f3702e22c178352524af18ec567781d51
Author: Yevgeny Kliteynik klit...@dev.mellanox.co.il
Date: Tue Mar 9 12:39:40 2010 +0200
libibumad: added link_layer for RoCEE support and updated umad
version
Added link_layer field to umad_port_t.
The field is implemented as char[].
If the relevant file doesn't exist in sysfs, the link layer
is IB. Otherwise, the content of link_layer file is used.
The libibumad version is promoted.
Signed-off-by: Yevgeny Kliteynik klit...@dev.mellanox.co.il
Signed-off-by: Sasha Khapyorsky sas...@voltaire.com
diff --git a/libibumad/include/infiniband/umad.h
b/libibumad/include/infiniband/umad.h
index 1f82183..f9da204 100644
--- a/libibumad/include/infiniband/umad.h
+++ b/libibumad/include/infiniband/umad.h
@@ -116,6 +116,7 @@ typedef struct ib_user_mad {
#define SYS_PORT_RATErate
#define SYS_PORT_GUIDport_guid
#define SYS_PORT_GID gids/0
+#define SYS_PORT_LINK_LAYER link_layer
typedef struct umad_port {
char ca_name[UMAD_CA_NAME_LEN];
@@ -132,6 +133,7 @@ typedef struct umad_port {
uint64_t port_guid;
unsigned pkeys_size;
uint16_t *pkeys;
+ char link_layer[UMAD_CA_NAME_LEN];
} umad_port_t;
typedef struct umad_ca {
diff --git a/libibumad/libibumad.ver b/libibumad/libibumad.ver
index 57cddbd..d36fbbc 100644
--- a/libibumad/libibumad.ver
+++ b/libibumad/libibumad.ver
@@ -6,4 +6,4 @@
# API_REV - advance on any added API
# RUNNING_REV - advance any change to the vendor files
# AGE - number of backward versions the API still supports
-LIBVERSION=2:1:0
+LIBVERSION=2:2:0
diff --git a/libibumad/src/umad.c b/libibumad/src/umad.c
index 277ae6b..d16e750 100644
--- a/libibumad/src/umad.c
+++ b/libibumad/src/umad.c
@@ -159,6 +159,11 @@ static int get_port(char *ca_name, char *dir, int
portnum, umad_port_t * port)
if (sys_read_uint(port_dir, SYS_PORT_CAPMASK, port-capmask)
0)
goto clean;
+ if (sys_read_string(port_dir, SYS_PORT_LINK_LAYER,
+ port-link_layer, UMAD_CA_NAME_LEN) 0)
+ /* assume IB by default */
+ sprintf(port-link_layer, IB);
+
port-capmask = htonl(port-capmask);
if (sys_read_gid(port_dir, SYS_PORT_GID, gid) 0)
Altering 'struct umad_port' effectively breaks ABI.
Sasha
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] libibumad.so version bump in OFED 1.5.2
I recently discovered that 3rd party applications built for OFED 1.5 will not run on OFED 1.5.2rc2. The issue I found was that libibumad had changed from version 2 to version 3. Can you provide insight as to why this change was made? In reviewing the source code and change logs there do not seem to be any changes which would impact the application API nor application ABI. I diffed the code and the main change seems to be: diff -r --exclude CVS ./src/src/umad.c-orig ./src/src/umad.c 161a162,166 if (sys_read_string(port_dir, SYS_PORT_LINK_LAYER, port-link_layer, UMAD_CA_NAME_LEN) 0) /* assume IB by default */ sprintf(port-link_layer, IB); The above change might imply an update to an rpm dependency on ib-kernel versions, but should not result in a new library version. If the library version remained at 2, then applications built for OFED 1.5 would also run on OFED 1.5.2rc2 without recompile. The ChangeLog simply says: ** Version: libibumad-1.3.4 Sun Dec 13 19:39:11 2009 +0200 Sasha Khapyorsky 2ebf19e61bb887b226017c0ac5a7f30ea0cd9e3f * management: package versions bump Sun Dec 13 19:36:19 2009 +0200 Sasha Khapyorsky b7f0e58ada74b4da01a39a9c5fd2f5517d70d26a * management: update library versions Tue Nov 17 14:39:37 2009 -0800 Ira Weiny f25da9f189638c1772d7c3cc5e1942b8d1e8abf8 * libibmad: libibumad: Print warnings and errors to stderr not stdout Todd Rimmer Chief Architect QLogic Network Systems Group Voice: 610-233-4852 Fax: 610-233-4777 todd.rim...@qlogic.com www.QLogic.com ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] pkey fix for ipoib - resubmission
Jason wrote: What happens if the SM reprograms the pkey table later? I'm not sure this is the right approach.. See the recent dicussion about using pkey indexes at all. Each ipoib interface is assigned a pkey, by number, not index. If the SM has not supplied that pkey to the port then the ipoib should not come up. If the SM adds it later then it should come up, if it the SM removes it later then it should go down. The default ipoib interface uses the default pkey. If your network need ipoib to use a different pkey then you have to change the pkey number assignment when the ipoib interface is created, not magically attempt to autoconfigure. I believe you cannot safely change the broadcast GID once the ipoib interface has started. The goal for IPoIB should be a mechanism which can mimic the ease of setting up VLANs in Ethernet. In Ethernet a default VLAN can be programmed into a switch in which case no configuration of the server is needed. Ethernet switch vendors often provide centralized tools for setting up VLANS in all the switches. It is only when you want a given server to participate in multiple VLANs that you need to setup specific configuration on the server to do so. For IB, the centralized tool is the SM and a VLAN is an IB Partition. The present capability of using the 1st PKey table entry is a nice simple and powerful way to mimic the ease of use of Ethernet VLANs. Only when a user wants IPoIB to run on two different partitions (which is rare) is a server specific configuration needed. When IPoIB sees a PKey table change, it will reregister with the broadcast GID. PKey table changes typically also involve a restart of the SM and hence a reregistration request is necessary anyway. Todd Rimmer Chief Architect QLogic Network Systems Group Voice: 610-233-4852 Fax: 610-233-4777 todd.rim...@qlogic.com www.QLogic.com ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] pkey fix for ipoib - resubmission
Jason, Fixing the maddr table, and dealing with race issues with ongoing joins my not be straightforward, but, IMHO, necessary for this patch to be acceptable. So you are pointing out an existing bug, which is no worse with this patch than without it. Namely that pkey changes with IPv6 may have issues. IPv4 pkey changes should be ok. In any case, this patch still successfully addresses the most important requirement of having a rebooted server come up with the correct MGID. In at least the HPC world, PKey changes are extremely rare, however having server's reliably boot is important. ipoib bonding had much the same problem with invalid maddrs, and a patch was put in that flushed the maddr table in certain bond scenarios. Perhaps something like that is a straightforward solution here as well? Perhaps that could be a second patch which would build on top of this initial fix for the most important requirement. It would seem that using the PKEY change and/or re-registration HCA events to trigger a maddr flush in IPoIB would be straightforward. If that approach worked well for bonding, it should work equally well in these cases. Todd Rimmer Chief Architect QLogic Network Systems Group Voice: 610-233-4852 Fax: 610-233-4777 todd.rim...@qlogic.com www.QLogic.com ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] RE: OFED libraries - on the web at last
From: Sasha Khapyorsky [mailto:sashakv...@gmail.com] On Behalf Of Sasha Khapyorsky Sent: Wednesday, June 17, 2009 11:32 AM To: Todd Rimmer Cc: Tziporet Koren; ewg@lists.openfabrics.org Subject: Re: [ewg] RE: OFED libraries - on the web at last On 08:14 Wed 17 Jun , Todd Rimmer wrote: The issue isn't with the management tree. It's with the mvapich included in OFED 1.4.1 and previous versions. Then it should be fixed. [Todd Rimmer] Agreed, but customers will need a few releases of notice that they should recompile their apps. It links with libibcommon and as a result, Do you know why exactly was it linked (and how)? I searched over mvapich source and didn't find any references in sources and makefiles. It is only mentioned in spec files. So is there any issue really? [Todd Rimmer] Yes, the .spec file controls what libraries mvapich uses, that same list of libraries is then part of mpicc and mpif77 and used to link all applications built with mvapich. ALL end user and ISV apps linked with mvapich also link with libibcommon. This means that in moving to OFED 1.5 end users and ISVs would have to recompile all their apps. Such a change should not be taken lightly. Instead we should provide what is needed in OFED 1.5 such that existing app binaries will continue to work (might be as simple as stubbed library). Then we can issue notice to end users and ISVs that their apps will need to be rebuilt and allow them at least 1 release to accomplish that. AFAIR libibcommon removal was discussed on the list couple of times before, during and after OFED-1.4. [Todd Rimmer] Yes, but unfortunately it didn't come into practice in mvapich in OFED 1.4.1 or previous. ABI compatibility is an important requirement. In this case the ABI is that of applications built with mvapich. Is it ideal, NO. But we can't penalize customers. I suspect a dummy library would satisfy the mvapich need, but that would need to be confirmed (FYI, OFED 1.4.1 libibumad also references ibcommon). Sasha ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] RE: OFED libraries - on the web at last
You are correct and this is actually old link. MPI will not use it in 1.5, since libibcommon was removed from the new management tree. I'm not sure what you mean by this statement. It's good that MPI in 1.5 will not use it. However, if we remove libibcommon from the library path in OFED 1.5 that would break existing applications. The fact that user apps have ended up being linked with it implies we must be very careful how we handle libibcommon. A case in point will be ISVs which have built against an older version of MPI and hence have this dependency in their application. Someone should see what routines in libibcommon (if any) MPI is using. A simple answer in OFED 1.5 might be to include a subset/dummy/empty libibcommon library to satisfy the application dependency. Todd Rimmer Chief Architect QLogic Network Systems Group Voice: 610-233-4852 Fax: 610-233-4777 todd.rim...@qlogic.com www.QLogic.com -Original Message- From: Tziporet Koren [mailto:tzipo...@dev.mellanox.co.il] Sent: Thursday, June 11, 2009 5:15 AM To: Todd Rimmer Cc: ewg@lists.openfabrics.org Subject: Re: [ewg] RE: OFED libraries - on the web at last Todd Rimmer wrote: What does this category mean: Private but used by some apps: This means that although these libraries were designed as private some apps/libs used them. We found this when we did this list. The apps should be changed not to use these libraries but this is the situation in 1.4.x This is the reason we publish such a list - so new apps will use only public libraries and will not count on any private library I see that libibcommon is in this category, however I have observed that mvapich and mvapich2, link with this library. Which in turn means that all MPI user applications built with mvapich or mvapich2 also link with it. You are correct and this is actually old link. MPI will not use it in 1.5, since libibcommon was removed from the new management tree. Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] RE: OFED libraries - on the web at last
libibcommon was removed from the new management package that will be part of OFED 1.5 The link in MPI was old and actually MPI does not use this library any more for a long time I beg to differ. I downloaded OFED 1.4.1 and it includes mvapich-1.1.0-3355.src.rpm Looking in that rpm, the mvapich.spec file requires ibcommon and uses it. If I build any apps with that version of mvapich, the apps end up with ibcommon in their ldd dependencies. At a more generic level, the golden rule should be to not require end users (or ISVs) to rebuild their apps. In this case it will be necessary for OFED 1.5 to include a libibcommon file which meets whatever requirements mvapich had. I see the use of ibcommon in mvapich.spec is mentioned as a 2007 addition to work on SLES10. Not sure what APIs in libibcommon (if any) were needed. Todd Rimmer Chief Architect QLogic Network Systems Group Voice: 610-233-4852 Fax: 610-233-4777 todd.rim...@qlogic.com www.QLogic.com -Original Message- From: Tziporet Koren [mailto:tzipo...@dev.mellanox.co.il] Sent: Thursday, June 11, 2009 11:09 AM To: Todd Rimmer Cc: tzipo...@dev.mellanox.co.il; ewg@lists.openfabrics.org Subject: Re: [ewg] RE: OFED libraries - on the web at last Todd Rimmer wrote: You are correct and this is actually old link. MPI will not use it in 1.5, since libibcommon was removed from the new management tree. I'm not sure what you mean by this statement. It's good that MPI in 1.5 will not use it. libibcommon was removed from the new management package that will be part of OFED 1.5 The link in MPI was old and actually MPI does not use this library any more for a long time Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ofa-general] Re: [ewg] RFC: Do we wish to take MPI out of OFED?
I agree with DK from OSU. There are clear advantages to having MPI included with OFED. Not only will it make testing of a complete solution easier by both OFED and MPI suppliers, but it will also improve ease of use for end users. As DK points out there are continual improvements in MPIs which may depend on bug fixes and/or new features in newer versions of OFED. Identifying a known good combination will be important to most end users, etc. I would point out that the OFED API seems to be holding up quite well. Applications which we built against OFED 1.3 have worked in binary form against OFED 1.4 and 1.4.1 without issue, in fact there are many cases where we build binaries for applications against OFED 1.3 and ship the same binary for use on both old and new OFED versions. However MPI has some differences in this area. In the constant search for better latency and bandwidth, there will be ongoing development and tuning. So in many cases the best performance for MPI will require the latest MPI and the latest OFED. This does not necessarily mean the API is broken, but rather it means a combination has been well tuned and tested. In most if not all cases, other combinations will work well, but may not achieve the same performance level. This is simply the nature of the HPC marketplace. Todd Rimmer Chief Architect QLogic Network Systems Group Voice: 610-233-4852 Fax: 610-233-4777 todd.rim...@qlogic.com www.QLogic.com -Original Message- From: general-boun...@lists.openfabrics.org [mailto:general- boun...@lists.openfabrics.org] On Behalf Of Dhabaleswar Panda Sent: Thursday, June 04, 2009 2:02 PM To: Tziporet Koren Cc: EWG; OpenFabrics General Subject: [ofa-general] Re: [ewg] RFC: Do we wish to take MPI out of OFED? Tziporet, Main reasons to keep MPI in OFED: - All participants test with the same MPI versions, and when installing OFED it is ensured that MPI will work fine with this version. - Customers convenience in install (no need to go to more sites to get MPI) - MPI is an important RDMA ULP and although it is not developed in OFA it is widely used by OFED customers I support keeping MPI packages in the OFED because of the above positive points you have mentioned. I would also like to mention that keeping MPI packages in OFED helps to test out various new features and functionalities (such as APM and XRC in the past and the new memory registration scheme being discussed now) as they get introduced. Such an integrated approach helps to test out these features at the lower layers as well as at the MPI layer. This process helps to resolve out any bugs with the new features during the testing process itself. It also accelerates the deployment and use of these new features in the community. However, to make the complete OFED release process work smoothly for everybody (vendors, distros, users, etc.) without affecting the release schedule, it is essential that stable MPI packages are added to OFED. This is what we have been doing wrt MVAPICH and MVAPICH2 for the last several years. If the developers of any MPI package do not want it to be a part of the OFED due to any constraints, it should be allowed. However, such an action should not force to remove all MPI packages. From the point of view of MVAPICH and MVAPICH2 packages in OFED, we have been providing stable packages to OFED for the last several years helping the OFED community and would like to continue with this process. Thanks, DK ___ general mailing list gene...@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib- general ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] shipping firmware with ofed
I have encountered many customers whose clusters are purposely not on the internet and hence could not perform a download. It would be best if the FW was included in the release. I think there is precedence with other Linux drivers which have included binary images of ASIC FW without having to release the source code. Todd Rimmer Chief Architect QLogic Network Systems Group Voice: 610-233-4852 Fax: 610-233-4777 todd.rim...@qlogic.com www.QLogic.com -Original Message- From: ewg-boun...@lists.openfabrics.org [mailto:ewg- boun...@lists.openfabrics.org] On Behalf Of John Russo Sent: Tuesday, March 03, 2009 1:19 PM To: Woodruff, Robert J; Steve Wise; tzipo...@dev.mellanox.co.il Cc: OpenFabrics EWG Subject: RE: [ewg] shipping firmware with ofed How about something along the lines of a firmware update tool built into OFED that checks the HCA for the proper firmware and gives the user to download the current version. It could automatically pull from Mellanox's site and therefore avoid the licensing issue while still providing a customer service. -Original Message- From: ewg-boun...@lists.openfabrics.org [mailto:ewg- boun...@lists.openfabrics.org] On Behalf Of Woodruff, Robert J Sent: Tuesday, March 03, 2009 1:17 PM To: Steve Wise; tzipo...@dev.mellanox.co.il Cc: OpenFabrics EWG Subject: RE: [ewg] shipping firmware with ofed Steve Wrote, I request that we do add this. Forcing customers to download firmware isn't very user friendly. It should be fairly easy to do, yes? I would take on the work involved to add the infrastructure needed... All that would be needed, I think, is to make a src rpm that allows generating an rpm that will install the firmware in /lib/firmware. Each provider could manage their own. Or we could have a firmware src rpm that holds all the providers' firmware images... Thoughts? Steve. If people submit firmware to ofed, then would it have to be submitted under the dual BSD/GPL license as agreed to in the OFA bylaws. If so, then you would probably have to submit the firmware source code as well, and I am not sure if you are willing to do that... woody ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] SLES10 X86_64 build problem found with 1.3rc4
Todd Rimmer Chief Architect QLogic System Interconnect Group Voice: 610-233-4852 Fax: 610-233-4777 [EMAIL PROTECTED] www.QLogic.com From: Sasha Khapyorsky [mailto:[EMAIL PROTECTED] Currently I cannot reproduce it with RHEL. Will try to find SLES10... [Todd Rimmer] It seems to only occur on SLES10, it worked fine on RHEL5 x86_64. I have not yet tried SLES10 ppc64 FYI, how do I go about getting a bugzilla account so I can enter problems like this directly into bugzilla? https://bugs.openfabrics.org/createaccount.cgi [Todd Rimmer] Thanks I have created an account and entered PR 942 to track this problem. Todd Rimmer ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
