RE: [ofa-general] RE: [ewg] RFC: Do we wish to take MPI out of OFED?
Tziporet, there is some guidance on this question from the Bylaws: ...ARTICLE 14. MAINTENANCE OF AND MODIFICATION TO OPENFABRICS SOFTWARE STACKS 14.1Updates. By a majority vote, the Board or its designated Working Group may at any time update an OpenFabrics software stack for the sole purpose of making error corrections or updates (e.g. a subnet manager change, additional driver, or operating system release synchronization) that do not substantially alter or augment the functionality or capabilities of an OpenFabrics software stack. The Board or Working Group may publish such updates subject to the terms of Article 13. 14.2Modification. Once an OpenFabrics software stack has been approved, published and released, any additions or alterations (but not updates) that substantially augment (e.g. a new transport, or operating system) the functionality and capability of such OpenFabrics software stack shall follow the procedures for approval of a Proposal in Article 12... However, as you may infer from the text, it also sort of bucks the question back to you. If the changes are characterized as updates, it takes a simple majority of the EWG. If the changes are modifications, the reference to section 12 requires a 2/3 majority. We have an XWG meeting tomorrow. Would you like to discuss the question then? Thanks, Jim -Original Message- From: ewg-boun...@lists.openfabrics.org [mailto:ewg-boun...@lists.openfabrics.org] On Behalf Of Tziporet Koren Sent: Tuesday, June 16, 2009 5:34 AM To: Woodruff, Robert J Cc: OpenFabrics General; EWG; Pavel Shamis (Pasha) Subject: Re: [ofa-general] RE: [ewg] RFC: Do we wish to take MPI out of OFED? Woodruff, Robert J wrote: I would agree, there is clearly no consensus on this one and I do not thing there is going to be. I think there has probably been enough discussion on this one. We can re-discuss it at the next EWG meeting, but I would say that given that lack of consensus, we should probably leave OFED as is, with the MPIs included. I will bring this subject again in our next EWG meeting. I have a procedural question: Till now we got all our decisions by consensus. Since there is no consensus on this subject - should we keep things as they are today or vote on the two options? If we vote - what should be the voting procedure? 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: [ofa-general] RE: [ewg] RFC: Do we wish to take MPI out of OFED?
On Jun 16, 2009, at 10:22 AM, Ryan, Jim wrote: Tziporet, there is some guidance on this question from the Bylaws: ...ARTICLE 14. MAINTENANCE OF AND MODIFICATION TO OPENFABRICS SOFTWARE STACKS 14.1Updates. By a majority vote, the Board or its designated Working Group may at any time update an OpenFabrics software stack for the sole purpose of making error corrections or updates (e.g. a subnet manager change, additional driver, or operating system release synchronization) that do not substantially alter or augment the functionality or capabilities of an OpenFabrics software stack. The Board or Working Group may publish such updates subject to the terms of Article 13. Has the XWG (or some other group) been voting on all the updates that have gone into OFED over the years? 14.2Modification. Once an OpenFabrics software stack has been approved, published and released, any additions or alterations (but not updates) that substantially augment (e.g. a new transport, or operating system) the functionality and capability of such OpenFabrics software stack shall follow the procedures for approval of a Proposal in Article 12... What does an OpenFabrics software stack mean -- is that specific to a release series such as 1.4.x? Or does it effectively mean the entire OF stack, regardless of version? I ask because the MPI change is proposed for v1.5. Since 1.5 doesn't exist yet, is it covered by 14.1 or 14.2? -- Jeff Squyres Cisco Systems ___ 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 think that up till now, there has not been any updates that have been so contentious that we needed a formal vote. I think that with most of the updates so far, there has been a general consensus to add things. -Original Message- From: Jeff Squyres [mailto:jsquy...@cisco.com] Sent: Tuesday, June 16, 2009 7:39 AM To: Ryan, Jim Cc: Tziporet Koren; Woodruff, Robert J; EWG; OpenFabrics General; Pavel Shamis (Pasha) Subject: Re: [ofa-general] RE: [ewg] RFC: Do we wish to take MPI out of OFED? On Jun 16, 2009, at 10:22 AM, Ryan, Jim wrote: Tziporet, there is some guidance on this question from the Bylaws: ...ARTICLE 14. MAINTENANCE OF AND MODIFICATION TO OPENFABRICS SOFTWARE STACKS 14.1Updates. By a majority vote, the Board or its designated Working Group may at any time update an OpenFabrics software stack for the sole purpose of making error corrections or updates (e.g. a subnet manager change, additional driver, or operating system release synchronization) that do not substantially alter or augment the functionality or capabilities of an OpenFabrics software stack. The Board or Working Group may publish such updates subject to the terms of Article 13. Has the XWG (or some other group) been voting on all the updates that have gone into OFED over the years? 14.2Modification. Once an OpenFabrics software stack has been approved, published and released, any additions or alterations (but not updates) that substantially augment (e.g. a new transport, or operating system) the functionality and capability of such OpenFabrics software stack shall follow the procedures for approval of a Proposal in Article 12... What does an OpenFabrics software stack mean -- is that specific to a release series such as 1.4.x? Or does it effectively mean the entire OF stack, regardless of version? I ask because the MPI change is proposed for v1.5. Since 1.5 doesn't exist yet, is it covered by 14.1 or 14.2? -- Jeff Squyres Cisco Systems ___ 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?
On Jun 16, 2009, at 10:57 AM, Woodruff, Robert J wrote: I think that up till now, there has not been any updates that have been so contentious that we needed a formal vote. I think that with most of the updates so far, there has been a general consensus to add things. Understood, but the quoted wording of the bylaws doesn't seem to have any leeway for consensus vs. voting. If this is the case, then the EWG has been acting outside of its charter. If the bylaws should be changed to allow for consensus, then I assume there's a process for that and that process should be initiated. My $0.02: self-created rules are only useful if they're followed. If they're not followed, they should be changed or thrown out. :-) -Original Message- From: Jeff Squyres [mailto:jsquy...@cisco.com] Sent: Tuesday, June 16, 2009 7:39 AM To: Ryan, Jim Cc: Tziporet Koren; Woodruff, Robert J; EWG; OpenFabrics General; Pavel Shamis (Pasha) Subject: Re: [ofa-general] RE: [ewg] RFC: Do we wish to take MPI out of OFED? On Jun 16, 2009, at 10:22 AM, Ryan, Jim wrote: Tziporet, there is some guidance on this question from the Bylaws: ...ARTICLE 14. MAINTENANCE OF AND MODIFICATION TO OPENFABRICS SOFTWARE STACKS 14.1Updates. By a majority vote, the Board or its designated Working Group may at any time update an OpenFabrics software stack for the sole purpose of making error corrections or updates (e.g. a subnet manager change, additional driver, or operating system release synchronization) that do not substantially alter or augment the functionality or capabilities of an OpenFabrics software stack. The Board or Working Group may publish such updates subject to the terms of Article 13. Has the XWG (or some other group) been voting on all the updates that have gone into OFED over the years? 14.2Modification. Once an OpenFabrics software stack has been approved, published and released, any additions or alterations (but not updates) that substantially augment (e.g. a new transport, or operating system) the functionality and capability of such OpenFabrics software stack shall follow the procedures for approval of a Proposal in Article 12... What does an OpenFabrics software stack mean -- is that specific to a release series such as 1.4.x? Or does it effectively mean the entire OF stack, regardless of version? I ask because the MPI change is proposed for v1.5. Since 1.5 doesn't exist yet, is it covered by 14.1 or 14.2? -- Jeff Squyres Cisco Systems -- Jeff Squyres Cisco Systems ___ 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 can see from the mails and from my personal experience that most of the end users do not need/use the MPI coming as part of OFED (they have many different MPI installed in their clusters), as we can see distro are not using it and also some (if not all) of OFED binary package providers (i.e. companies) do not use it. We think that the simple clear answer is: take the MPI packages out of OFED It is not so simple and clear for me after all this discussion on the thread. Some OFED member want to remove MPIs and some strongly against it (the same correct for OFED user community too). As I mentioned previously I sure that this step will push users from OFED distributions towards vendors packages, like it was before first OFED release. What will you answer on user's question: How can I install MPI with OFED support ? Will you send user to read 10 pages of MPI Installation FAQ ? :-) My 0.02 $ Pasha ___ 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?
On Jun 15, 2009, at 9:52 AM, Pavel Shamis (Pasha) wrote: We think that the simple clear answer is: take the MPI packages out of OFED It is not so simple and clear for me after all this discussion on the thread. Some OFED member want to remove MPIs and some strongly against it (the same correct for OFED user community too). It speaks volumes to me that Red Hat has told us -- repeatedly -- that this is bad software engineering, not what the rest of the Linux community does, and has specifically asked us not to do it. But yet we still do. The main objection so far seems to have been but we want to include MPI (the co-development arguments do not make sense for OFED *distribution*). As I mentioned previously I sure that this step will push users from OFED distributions towards vendors packages, like it was before first OFED release. Perhaps it's time that we start discussion of how the every vendor has incompatible/different OFED distributions is far worse than including MPI. As I indicated earlier, we're back to the bad old days of mVAPI. This compatibility stuff is confusing enough for those of us who are in the industry and working with this stuff every day -- can you imagine being a customer just trying to get a bug fix? What will you answer on user's question: How can I install MPI with OFED support ? Will you send user to read 10 pages of MPI Installation FAQ ? :-) Many customers are in the habit of downloading/installing MPI manually, anyway, since they want to be on the bleeding edge of releases (as has been stated on this list). For customers who just want an MPI that works, a simple installation guide, and/or getting the MPI's to distribute binaries, and/or having customers download MPI's from the distros are all viable solutions. In short: these are all solvable problems. More specifically: wasn't OFED created to solve the problem of mVAPI ! = mVAPI != mVAPI? If so, it has failed. There are two obvious solutions (and probably others): 1. Test together and only use the distros to distribute new versions, or 2. Use better packaging such that vendors can *contribute* their own technology without effectively making (potentially incompatible) forks of OFED. -- Jeff Squyres Cisco Systems ___ 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?
Pasha wrote, It is not so simple and clear for me after all this discussion on the thread. Some OFED member want to remove MPIs and some strongly against it (the same correct for OFED user community too). I would agree, there is clearly no consensus on this one and I do not thing there is going to be. I think there has probably been enough discussion on this one. We can re-discuss it at the next EWG meeting, but I would say that given that lack of consensus, we should probably leave OFED as is, with the MPIs included. woody ___ 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?
On Jun 8, 2009, at 6:59 AM, Todd Rimmer wrote: 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, Can you specify how, specifically? Remember that all that Open MPI and MVAPICH do is provide SRPMs. There is no co-mingling of development / source trees, for example. You seem to be blurring the distinction between co-development of MPI +OpenFabrics and shipping OFED. Developing the two together is a Good Thing -- and that happens. But that is unrelated to shipping the MPI's in OFED. As has been specified multiple times on this thread, using MPI to test verbs is a Good Thing and it can easily be maintained without distributing MPI in OFED. but it will also improve ease of use for end users. Can you specify how, specifically? Recall that: - Open MPI users get a stripped-down version with several important features disabled - At least one user has chimed in that they install MPI separately from OFED for a variety of reasons (I have seen this at customer sites as well) 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. Easy to do in documentation and/or in the technology of the MPI implementations themselves. The verbs API should allow this kind of run-time checking as a matter of course (and it seems to allow it well enough). Additionally -- and your later comments seemed to support it -- possibly the most important combination that needs to work is that of latest OFED + latest MPI, which will continue to work because OFED would be insane to remove MPI from its testing/QA/release process. -- Jeff Squyres Cisco Systems ___ 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: [ofa-general] RE: [ewg] RFC: Do we wish to take MPI out of OFED?
On Fri, 2009-06-05 at 09:44 -0400, Jeff Squyres wrote: 3. As Doug described, packaging MPI and OFED together actually makes it *harder* for distros. Remember that RHEL and SUSE don't end up using any of the OFED packaging; they essentially use the individual SRPMs. One minor clarification, it's not so much the RPM packaging that makes things difficult, it's the compatibility matrix. Since things aren't designed to cleanly inter-operate with each other in anything other than very specific combinations, it means that updates are an all or nothing affair. This is in direct contrast to the rest of our entire operating system where we isolate and target things that need fixed and only things that need fixed. -- Doug Ledford dledf...@redhat.com 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
RE: [ofa-general] RE: [ewg] RFC: Do we wish to take MPI out of OFED?
Doug wrote, One minor clarification, it's not so much the RPM packaging that makes things difficult, it's the compatibility matrix. Since things aren't designed to cleanly inter-operate with each other in anything other than very specific combinations, it means that updates are an all or nothing affair. This is in direct contrast to the rest of our entire operating system where we isolate and target things that need fixed and only things that need fixed. I think this was true early on with the OFA and OFED releases, but I do think things are stabilizing in this area as the code has matured and thus I think that having various components decoupled should be easier going forward. So from a technical standpoint, I do not see a problem with removing MPIs from OFED. I can however see the benefit of that packaging from a customer point of view in making it easier to install without having to go get packages from multiple places. I personally do not really care either way as I use Intel MPI for my testing, and BTW, Intel MPI has always been decoupled and we have not seen this to be a problem. We have recommended people install newer versions of OFED from time to time as MPI found bugs that were fixed in the newer OFED, but it was not the API that was not stable, it was just bugs that were found that required a newer OFED version. woody ___ 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?
On Sun, 2009-06-07 at 13:51 -0700, Woodruff, Robert J wrote: Doug wrote, One minor clarification, it's not so much the RPM packaging that makes things difficult, it's the compatibility matrix. Since things aren't designed to cleanly inter-operate with each other in anything other than very specific combinations, it means that updates are an all or nothing affair. This is in direct contrast to the rest of our entire operating system where we isolate and target things that need fixed and only things that need fixed. I think this was true early on with the OFA and OFED releases, but I do think things are stabilizing in this area as the code has matured and thus I think that having various components decoupled should be easier going forward. For most things this is true, but not for all. BTW, Intel MPI has always been decoupled and we have not seen this to be a problem. We have recommended people install newer versions of OFED from time to time as MPI found bugs that were fixed in the newer OFED, but it was not the API that was not stable, it was just bugs that were found that required a newer OFED version. I don't know the particulars of how Intel MPI is distributed, built, etc. But, when you tell me that you have from time to time recommended customers install a later version of OFED to get a bug fix, I get the impression that you start off by telling customers that OFED is a prerequisite to running Intel MPI in the first place. If that's the case, then I would question whether that's decoupled from OFED, or just not in the OFED tarball. -- Doug Ledford dledf...@redhat.com 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
Re: [ofa-general] RE: [ewg] RFC: Do we wish to take MPI out of OFED?
A few clarifications are probably worthwhile at this point. 1. No one is suggesting divorcing MPI from the OFED testing/release cycle. It's obviously a Good Thing (and has been stated multiple times on this thread). It is easy to indicate good combos of MPI and OFED in documentation and web pages. However, most users expect the latest MPI implementation versions to work with the latest version of OFED (which is not unreasonable). Looking for compatibility between older MPI/OFED versions is something that is almost always relegated to googling. 2. The distinction between development and release phases seems to have been blurred in this discussion. The development phase is where MPI's collaborate with verbs developers to test new APIs, functionality, etc. OFED is the final product, not the development phase. Hence, I'm not sure that the point of continual improvements in MPI depend on bug fixes/new features in OFED is relevant. 3. As Doug described, packaging MPI and OFED together actually makes it *harder* for distros. Remember that RHEL and SUSE don't end up using any of the OFED packaging; they essentially use the individual SRPMs. On Jun 5, 2009, at 8:37 AM, John Russo wrote: 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 and ease of inclusion for linux distro suppliers. 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. -Original Message- From: ewg-boun...@lists.openfabrics.org [mailto:ewg-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: 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 ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg ___ 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 -- Jeff Squyres Cisco Systems ___ 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?
On Fri, Jun 05, 2009 at 09:44:09AM -0400, Jeff Squyres wrote: 3. As Doug described, packaging MPI and OFED together actually makes it *harder* for distros. Remember that RHEL and SUSE don't end up using any of the OFED packaging; they essentially use the individual SRPMs. I would almost say the entire OFED process is making it harder for the distros, and I mean that in a very general sense. A working IB stack has been in the kernel for a long time now. Can I install Fedora Core, Ubuntu, Debian, etc and have all the necessary IB tools and diagostics available? Nope. IMHO, the entire process would be better served if OFA focused on producing a bleeding edge environment within the community distributions (Fedora, Debian, OpenSuse, etc) and testing that entire stack, including MPIs included in the distro. If this had been done from the start I would have a complete IB stack available in every single distribution TODAY. The truth is, within the Linux world, if you want bleeding edge stuff you use something like FC or Debian Unstable. Otherwise you settle for older, hopefully more tested stuff. The OFED distribution ontop of a distribution is just weird and painfull... For selectivly moving an old distro forward I would *much* rather have true backport packages that exactly match in form and function the native packages in my distro with new versions. That is a far safer path if I actually care about not disrupting my core distribution. Jason ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
