Re: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3 readiness
Yes this is better, I have no particular objections to these changes and appreciate your efforts to hold the line on the OFED 1.3 schedule. Thanks, Bob Tziporet Koren wrote: The main reason is not the bugs but the features supported by IBM - CM support for non SRQ and 4K MTU I see that these are important for IBM (see other mails) Another thing we can do in order not to delay the release is insert the changes tomorrow (immediately after RC3 is out) and do RC4 next week (instead of 2 weeks between every RC), and RC5 the week after. In this way we will have enough time for testing and if we find some bug we can fix then in RC5 Is this better? Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3 readiness
At 09:16 PM 1/30/2008, Chet Mehta wrote: Robert, In response to your question.. A more general question I would like to ask the group is how many people use OFED from the RH or SUSE distros as is, as compared with using OFED releases from other sources like the IB vendors, or building their own from openfabrics.org? We use RH distros, but to this point, the OFED support provided in RH distros has lagged behind the latest releases available from openfabrics.org. This is not to fault Red Hat, but OFED is still changing too rapidly, with minor point releases and bug fixes, for a distro to keep up. I think many of us hope that someday that will not be the case, but appears to be true for the foreseeable future. Right now, our mode of operation is to remove whatever IB support comes in the distro and replace it, so it does not help us to delay OFED 1.3 to get a particular bug fix in a distro. We have found that there are some vendors who dictate that they will only support a Distro EX: RHXXX. Then if you layer the latest OFED on top, then the support is nullified. Or to get any bug fixes or support you have to uninstall the what you did and repeat the bug/error. SO I think it is very important to keep the Distros very close the latest OFED stack. I believe the question that should be asked is 'How many IB customers would like to use the OFED distribution if provided by the distro? The answer at least for the customer set we deal with is pretty much unanimous. The fact is that customers are already dealing with a distro for their base OS so obtaining the interconnect code support from the same sources is highly desirable. When OpenIB was new (in 2004/5) and common IB code was still in its infancy, the customer set was tolerant of 'build your own' or vendor provided distribution mechanism. However if IB is to become a ubiquitous interconnect, we in OFA have to strive to tailor our deliverables to meet distro requirements. Until we do that, IB will have difficultly gaining broader market acceptance. Just my perspective. :Chet. ___ general mailing list [EMAIL PROTECTED] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general * Correspondence * This email contains no programmatic content that requires independent ADC review ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3 readiness
Conversely, there are some vendors who will *not* support OFED from a distro, but only a version they supply and control. The customers I work with are more sensitive to performance, as well as quick turnaround for bug fixes, so having the latest releases, and being able to update them quickly is critical. I agree that for other customers, a more slowly changing supported stack is suitable. These may also be the same customers more likely to use 10GE. I agree more discussion and adjustment is needed for OFED to be able to balance the needs of the spectrum of users, from the latest kernel.org users, IB vendor based users and distro based users. Bob Parks Fields wrote: At 09:16 PM 1/30/2008, Chet Mehta wrote: Robert, In response to your question.. A more general question I would like to ask the group is how many people use OFED from the RH or SUSE distros as is, as compared with using OFED releases from other sources like the IB vendors, or building their own from openfabrics.org? We use RH distros, but to this point, the OFED support provided in RH distros has lagged behind the latest releases available from openfabrics.org. This is not to fault Red Hat, but OFED is still changing too rapidly, with minor point releases and bug fixes, for a distro to keep up. I think many of us hope that someday that will not be the case, but appears to be true for the foreseeable future. Right now, our mode of operation is to remove whatever IB support comes in the distro and replace it, so it does not help us to delay OFED 1.3 to get a particular bug fix in a distro. We have found that there are some vendors who dictate that they will only support a Distro EX: RHXXX. Then if you layer the latest OFED on top, then the support is nullified. Or to get any bug fixes or support you have to uninstall the what you did and repeat the bug/error. SO I think it is very important to keep the Distros very close the latest OFED stack. I believe the question that should be asked is 'How many IB customers would like to use the OFED distribution if provided by the distro? The answer at least for the customer set we deal with is pretty much unanimous. The fact is that customers are already dealing with a distro for their base OS so obtaining the interconnect code support from the same sources is highly desirable. When OpenIB was new (in 2004/5) and common IB code was still in its infancy, the customer set was tolerant of 'build your own' or vendor provided distribution mechanism. However if IB is to become a ubiquitous interconnect, we in OFA have to strive to tailor our deliverables to meet distro requirements. Until we do that, IB will have difficultly gaining broader market acceptance. Just my perspective. :Chet. ___ general mailing list [EMAIL PROTECTED] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general * Correspondence * This email contains no programmatic content that requires independent ADC review ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3 readiness
Doug Ledford wrote: Hmmm...I'd like to put my $.02 in here. I don't have any visibility into what drives the OFED schedule, so I have no clue as to why people don't want to slip the schedule for this change. I'm sure you guys have your reasons. However, I also happen to be a consumer of this code, and I know for a fact that no one has gotten my input on this issue. So, the deal is that I'm currently integrating OFED 1.3 into what will be RHEL5.2. The RHEL5.2 freeze date has already passed, but in order to keep what finally goes out from being too stale, I'm being allowed to submit the OFED-1.3-rc1 code prior to freeze, and then update to OFED-1.3 final during our beta test process. What this means, is that anything you punt from 1.3 to 1.3.1, you are also punting out of RHEL5.2 and RHEL4.7. So, that being said, there's a whole trickle down effect with various groups that would really like to be able to use 5.2 out of the box that may prefer a slip in 1.3 so that this can be part of it instead of punting to 1.3.1. I'm not saying this will change your mind, but I'm sure it wasn't part of the decision process before, so I'm bringing it up. Thanks for the input (BTW you are welcome to join our weekly meetings and give us feedback online) I think it is important to make sure RH new versions will include best OFED release This my suggestion is: * Delay 1.3 release in a week * Do RC4 next week - Feb 6 * Add RC5 on Feb 18 - this will be the GOLD version * GA release on Feb 25 All - please reply if this is acceptable 760 major [EMAIL PROTECTED] UDP performance on Rx is lower than Tx - for 1.3.1 761 major [EMAIL PROTECTED] Poor and jittery UDP performance at small messages - for 1.3.1 Ditto for requesting these two be in 1.3. We've already had customers bring up the UDP performance issue in our previous releases. We will push some fixes of these to RC4 if the above plan is accepted Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3 readiness
When do you pack the official RC3 ? Thanks. --CQ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tziporet Koren Sent: Wednesday, January 30, 2008 10:40 AM To: Doug Ledford Cc: ewg@lists.openfabrics.org; [EMAIL PROTECTED] Subject: Re: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3 readiness Doug Ledford wrote: Hmmm...I'd like to put my $.02 in here. I don't have any visibility into what drives the OFED schedule, so I have no clue as to why people don't want to slip the schedule for this change. I'm sure you guys have your reasons. However, I also happen to be a consumer of this code, and I know for a fact that no one has gotten my input on this issue. So, the deal is that I'm currently integrating OFED 1.3 into what will be RHEL5.2. The RHEL5.2 freeze date has already passed, but in order to keep what finally goes out from being too stale, I'm being allowed to submit the OFED-1.3-rc1 code prior to freeze, and then update to OFED-1.3 final during our beta test process. What this means, is that anything you punt from 1.3 to 1.3.1, you are also punting out of RHEL5.2 and RHEL4.7. So, that being said, there's a whole trickle down effect with various groups that would really like to be able to use 5.2 out of the box that may prefer a slip in 1.3 so that this can be part of it instead of punting to 1.3.1. I'm not saying this will change your mind, but I'm sure it wasn't part of the decision process before, so I'm bringing it up. Thanks for the input (BTW you are welcome to join our weekly meetings and give us feedback online) I think it is important to make sure RH new versions will include best OFED release This my suggestion is: * Delay 1.3 release in a week * Do RC4 next week - Feb 6 * Add RC5 on Feb 18 - this will be the GOLD version * GA release on Feb 25 All - please reply if this is acceptable 760 major [EMAIL PROTECTED] UDP performance on Rx is lower than Tx - for 1.3.1 761 major [EMAIL PROTECTED] Poor and jittery UDP performance at small messages - for 1.3.1 Ditto for requesting these two be in 1.3. We've already had customers bring up the UDP performance issue in our previous releases. We will push some fixes of these to RC4 if the above plan is accepted Tziporet ___ general mailing list [EMAIL PROTECTED] 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
[ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3 readiness
I would prefer not to see OFED 1.3 delayed for this. There will always be another bug, so you have to close the release and ship at some point. In the case of these particular bugs, IIRC, the first involved an older HCA that may not be widely used. The other UDP performance bugs do not have any ready fixes that I'm aware of. A more general question I would like to ask the group is how many people use OFED from the RH or SUSE distros as is, as compared with using OFED releases from other sources like the IB vendors, or building their own from openfabrics.org? We use RH distros, but to this point, the OFED support provided in RH distros has lagged behind the latest releases available from openfabrics.org. This is not to fault Red Hat, but OFED is still changing too rapidly, with minor point releases and bug fixes, for a distro to keep up. I think many of us hope that someday that will not be the case, but appears to be true for the foreseeable future. Right now, our mode of operation is to remove whatever IB support comes in the distro and replace it, so it does not help us to delay OFED 1.3 to get a particular bug fix in a distro. Bob -Original Message- ... Doug Ledford wrote: Hmmm...I'd like to put my $.02 in here. I don't have any visibility into what drives the OFED schedule, so I have no clue as to why people don't want to slip the schedule for this change. I'm sure you guys have your reasons. However, I also happen to be a consumer of this code, and I know for a fact that no one has gotten my input on this issue. So, the deal is that I'm currently integrating OFED 1.3 into what will be RHEL5.2. The RHEL5.2 freeze date has already passed, but in order to keep what finally goes out from being too stale, I'm being allowed to submit the OFED-1.3-rc1 code prior to freeze, and then update to OFED-1.3 final during our beta test process. What this means, is that anything you punt from 1.3 to 1.3.1, you are also punting out of RHEL5.2 and RHEL4.7. So, that being said, there's a whole trickle down effect with various groups that would really like to be able to use 5.2 out of the box that may prefer a slip in 1.3 so that this can be part of it instead of punting to 1.3.1. I'm not saying this will change your mind, but I'm sure it wasn't part of the decision process before, so I'm bringing it up. Thanks for the input (BTW you are welcome to join our weekly meetings and give us feedback online) I think it is important to make sure RH new versions will include best OFED release This my suggestion is: * Delay 1.3 release in a week * Do RC4 next week - Feb 6 * Add RC5 on Feb 18 - this will be the GOLD version * GA release on Feb 25 All - please reply if this is acceptable 760 major eli at mellanox.co.il UDP performance on Rx is lower than Tx - for 1.3.1 761 major eli at mellanox.co.il Poor and jittery UDP performance at small messages - for 1.3.1 Ditto for requesting these two be in 1.3. We've already had customers bring up the UDP performance issue in our previous releases. We will push some fixes of these to RC4 if the above plan is accepted Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3 readiness
[EMAIL PROTECTED] wrote on 01/30/2008 08:40:10 AM: Doug Ledford wrote: Hmmm...I'd like to put my $.02 in here. I don't have any visibility into what drives the OFED schedule, so I have no clue as to why people don't want to slip the schedule for this change. I'm sure you guys have your reasons. However, I also happen to be a consumer of this code, and I know for a fact that no one has gotten my input on this issue. So, the deal is that I'm currently integrating OFED 1.3 into what will be RHEL5.2. The RHEL5.2 freeze date has already passed, but in order to keep what finally goes out from being too stale, I'm being allowed to submit the OFED-1.3-rc1 code prior to freeze, and then update to OFED-1.3 final during our beta test process. What this means, is that anything you punt from 1.3 to 1.3.1, you are also punting out of RHEL5.2 and RHEL4.7. So, that being said, there's a whole trickle down effect with various groups that would really like to be able to use 5.2 out of the box that may prefer a slip in 1.3 so that this can be part of it instead of punting to 1.3.1. I'm not saying this will change your mind, but I'm sure it wasn't part of the decision process before, so I'm bringing it up. Thanks for the input (BTW you are welcome to join our weekly meetings and give us feedback online) I think it is important to make sure RH new versions will include best OFED release This my suggestion is: * Delay 1.3 release in a week * Do RC4 next week - Feb 6 * Add RC5 on Feb 18 - this will be the GOLD version * GA release on Feb 25 All - please reply if this is acceptable 760 major [EMAIL PROTECTED] UDP performance on Rx is lower than Tx - for 1.3.1 761 major [EMAIL PROTECTED] Poor and jittery UDP performance at small messages - for 1.3.1 Ditto for requesting these two be in 1.3. We've already had customers bring up the UDP performance issue in our previous releases. We will push some fixes of these to RC4 if the above plan is accepted Tziporet Is also that possible to include some delayed features which are planning to be in later release as well? Like IPoIB noSRQ, 4K mtu etc, we do have some customers request already. IPoIB noSRQ has been in upper stream already, but it's not in 2.6.24, it will be in 2.6.25. 4K mtu patch is under review. We have passed our tests. I will post a new version against RC3, and split the patch into several for 2.6.25 upper stream submission. thanks Shirley___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3 readiness
Tang, Changqing wrote: When do you pack the official RC3 ? Thanks. Already packed - mail will go out soon Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3 readiness
Kossey, Robert wrote: I would prefer not to see OFED 1.3 delayed for this. There will always be another bug, so you have to close the release and ship at some point. In the case of these particular bugs, IIRC, the first involved an older HCA that may not be widely used. The other UDP performance bugs do not have any ready fixes that I'm aware of. A more general question I would like to ask the group is how many people use OFED from the RH or SUSE distros as is, as compared with using OFED releases from other sources like the IB vendors, or building their own from openfabrics.org? We use RH distros, but to this point, the OFED support provided in RH distros has lagged behind the latest releases available from openfabrics.org. This is not to fault Red Hat, but OFED is still changing too rapidly, with minor point releases and bug fixes, for a distro to keep up. I think many of us hope that someday that will not be the case, but appears to be true for the foreseeable future. Right now, our mode of operation is to remove whatever IB support comes in the distro and replace it, so it does not help us to delay OFED 1.3 to get a particular bug fix in a distro. The main reason is not the bugs but the features supported by IBM - CM support for non SRQ and 4K MTU I see that these are important for IBM (see other mails) Another thing we can do in order not to delay the release is insert the changes tomorrow (immediately after RC3 is out) and do RC4 next week (instead of 2 weeks between every RC), and RC5 the week after. In this way we will have enough time for testing and if we find some bug we can fix then in RC5 Is this better? Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3 readiness
One of the things driving the OFED 1.3 date is that OFED 1.3 has to be released before the Plugfest, which starts on March 10. I can deal with slipping OFED GA date to Feb 25, but I really don't think we should let it slip into March. How confident are the developers that, if they get the extra week, there won't be further slippage? Doug - thanks very much for letting us know the plans for RHEL5 U2 - it's great news that OFED 1.3 (final release) will be included. - Betsy On Wed, 2008-01-30 at 18:40 +0200, Tziporet Koren wrote: Doug Ledford wrote: Hmmm...I'd like to put my $.02 in here. I don't have any visibility into what drives the OFED schedule, so I have no clue as to why people don't want to slip the schedule for this change. I'm sure you guys have your reasons. However, I also happen to be a consumer of this code, and I know for a fact that no one has gotten my input on this issue. So, the deal is that I'm currently integrating OFED 1.3 into what will be RHEL5.2. The RHEL5.2 freeze date has already passed, but in order to keep what finally goes out from being too stale, I'm being allowed to submit the OFED-1.3-rc1 code prior to freeze, and then update to OFED-1.3 final during our beta test process. What this means, is that anything you punt from 1.3 to 1.3.1, you are also punting out of RHEL5.2 and RHEL4.7. So, that being said, there's a whole trickle down effect with various groups that would really like to be able to use 5.2 out of the box that may prefer a slip in 1.3 so that this can be part of it instead of punting to 1.3.1. I'm not saying this will change your mind, but I'm sure it wasn't part of the decision process before, so I'm bringing it up. Thanks for the input (BTW you are welcome to join our weekly meetings and give us feedback online) I think it is important to make sure RH new versions will include best OFED release This my suggestion is: * Delay 1.3 release in a week * Do RC4 next week - Feb 6 * Add RC5 on Feb 18 - this will be the GOLD version * GA release on Feb 25 All - please reply if this is acceptable 760 major [EMAIL PROTECTED] UDP performance on Rx is lower than Tx - for 1.3.1 761 major [EMAIL PROTECTED] Poor and jittery UDP performance at small messages - for 1.3.1 Ditto for requesting these two be in 1.3. We've already had customers bring up the UDP performance issue in our previous releases. We will push some fixes of these to RC4 if the above plan is accepted Tziporet ___ 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] Re: [ofa-general] OFED Jan 28 meeting summary on RC3 readiness
Robert, In response to your question.. A more general question I would like to ask the group is how many people use OFED from the RH or SUSE distros as is, as compared with using OFED releases from other sources like the IB vendors, or building their own from openfabrics.org? We use RH distros, but to this point, the OFED support provided in RH distros has lagged behind the latest releases available from openfabrics.org. This is not to fault Red Hat, but OFED is still changing too rapidly, with minor point releases and bug fixes, for a distro to keep up. I think many of us hope that someday that will not be the case, but appears to be true for the foreseeable future. Right now, our mode of operation is to remove whatever IB support comes in the distro and replace it, so it does not help us to delay OFED 1.3 to get a particular bug fix in a distro. I believe the question that should be asked is 'How many IB customers would like to use the OFED distribution if provided by the distro? The answer at least for the customer set we deal with is pretty much unanimous. The fact is that customers are already dealing with a distro for their base OS so obtaining the interconnect code support from the same sources is highly desirable. When OpenIB was new (in 2004/5) and common IB code was still in its infancy, the customer set was tolerant of 'build your own' or vendor provided distribution mechanism. However if IB is to become a ubiquitous interconnect, we in OFA have to strive to tailor our deliverables to meet distro requirements. Until we do that, IB will have difficultly gaining broader market acceptance. Just my perspective. :Chet.___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3 readiness
On Tue, 2008-01-29 at 14:21 +0200, Tziporet Koren wrote: OFED Jan 28 meeting summary on RC3 readiness: = 1. OFED 1.3 readiness toward RC3 this week * RC3 is based on the official 2.6.24 release * RC3 is expected on Wed * RC4 is planned for Feb 13 2. All companies update: * IBM - ready for RC3 * Voltaire - ready for RC3 * Qlogic - ready for RC3; will work on bug 874 * Intel - things looks good. Need some uDAPL update from Arlin * Chelsio - ready for RC3 * NetEffect - ready for RC3 * Cisco - reported all issues in bugzilla * Mellanox - ready for RC3 * MPI - all packages are ready 3. Request to change IPoIB to support CM without SRQ and 4K MTU Decided that we cannot insert such enhancements at this stage (RC3 built today) without delaying the release since IPoIB is a critical ULP used by all customers. Since we do not want to delay the release and we wish to have a solution for the new IPoIB enhancements we plan to have 1.3.1 release Hmmm...I'd like to put my $.02 in here. I don't have any visibility into what drives the OFED schedule, so I have no clue as to why people don't want to slip the schedule for this change. I'm sure you guys have your reasons. However, I also happen to be a consumer of this code, and I know for a fact that no one has gotten my input on this issue. So, the deal is that I'm currently integrating OFED 1.3 into what will be RHEL5.2. The RHEL5.2 freeze date has already passed, but in order to keep what finally goes out from being too stale, I'm being allowed to submit the OFED-1.3-rc1 code prior to freeze, and then update to OFED-1.3 final during our beta test process. What this means, is that anything you punt from 1.3 to 1.3.1, you are also punting out of RHEL5.2 and RHEL4.7. So, that being said, there's a whole trickle down effect with various groups that would really like to be able to use 5.2 out of the box that may prefer a slip in 1.3 so that this can be part of it instead of punting to 1.3.1. I'm not saying this will change your mind, but I'm sure it wasn't part of the decision process before, so I'm bringing it up. AIs: Tziporet to define the 1.3.1 release (scope of changes, schedule etc.) Vlad: open 1_3_1 branch so people will have a place to commit changes. We will not start any daily build before 1.3 release 3. Review high priority bugs: 846 critical[EMAIL PROTECTED]SDP crash on RHEL5 ppc64 running netserver - will be debugged 859 critical[EMAIL PROTECTED] Bonding configuration on Sles10 sp1 is not loaded consistently - fixed 863 critical[EMAIL PROTECTED] ib-bonding won't compile for RHEL4 U6 - fixed 874 critical[EMAIL PROTECTED] Intel MPI (IMB test) hangs intermittently on the qlogic HCA - will be debugged by Qlogic 760 major [EMAIL PROTECTED] UDP performance on Rx is lower than Tx - for 1.3.1 761 major [EMAIL PROTECTED] Poor and jittery UDP performance at small messages - for 1.3.1 Ditto for requesting these two be in 1.3. We've already had customers bring up the UDP performance issue in our previous releases. 869 major [EMAIL PROTECTED]mstflint won't build on SLES10 x86 - fixed 736 major [EMAIL PROTECTED] IBV_WC_RETRY_EXC_ERR errors with local rdma_reads - seems a FW issue (Mellanox to debug) 767 major [EMAIL PROTECTED] Non backport Kernels that don't build in genalloc cause compile errors for cxgb3 - no fix (document) And we still need to get actual downloads for a number of the srpms in OFED-1.3. The various spec files list fictitious tarballs that aren't actually available on the download server. While that works for the rcs, they really need to have a tarball up there for final. -- Doug Ledford [EMAIL PROTECTED] GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband signature.asc Description: This is a digitally signed message part ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
