[ewg] ***SPAM*** Request to track fixed PRs
Can we add a Fixed in field to OFED's Bugzilla. Then when a PR gets fixed we would know what OFED release the fix was added to. Right now there doesn't seem to be a good way to identify the problems that have been corrected in a release without pouring through a ton of emails. This would be a quick and easy fix that would help a number of people. [cid:image001.jpg@01CA0176.99106E40] John F. Russo Engineering Manager QLogic Corporation 780 Fifth Avenue Suite 140 King of Prussia, PA 19406 Direct: 610-233-4866 Fax: 610-233-4777 Cell: 610-246-9903 www.qlogic.comhttp://www.qlogic.com inline: image001.jpg___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
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 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 ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] WinOF applications
WinOF actually supports Microsoft MPI over Network Direct on Windows 2008 HPC -Original Message- From: ewg-boun...@lists.openfabrics.org [mailto:ewg-boun...@lists.openfabrics.org] On Behalf Of Jeff Squyres Sent: Monday, June 01, 2009 12:28 PM To: Steve Wise Cc: OpenFabrics EWG Subject: Re: [ewg] WinOF applications Correct -- Open MPI does not use WinOF. On Jun 1, 2009, at 12:22 PM, Steve Wise wrote: Can someone point me to documentation or email threads that define what apps actually run over WinOF on Windows Server 2008? For instance, are there any MPIs that run on this? I believe Open MPI does not. -- Jeff Squyres Cisco Systems ___ 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] RE: Delaying next Monday OFED meeting
Let's go for the 12th. From: ewg-boun...@lists.openfabrics.org [mailto:ewg-boun...@lists.openfabrics.org] On Behalf Of Tziporet Koren Sent: Thursday, March 05, 2009 7:23 AM To: ewg@lists.openfabrics.org Subject: [ewg] Delaying next Monday OFED meeting Hello, Due to Purim holiday in Israel I wish to delay the next Monday OFED meeting. We can do it next week on Thursday (12 March) 9am PST or delay to a week after on Monday (March 16 ) 9am PST Can you reply with your availability? Sorry for this inconvenient. Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
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] RE: OFED (EWG) meeting agenda for today (Feb 23)
Betsy can't make it today. I will be covering for her. Worst case, I will cover the items that you listed. -Original Message- From: ewg-boun...@lists.openfabrics.org [mailto:ewg-boun...@lists.openfabrics.org] On Behalf Of Tziporet Koren Sent: Monday, February 23, 2009 11:11 AM To: ewg@lists.openfabrics.org Cc: gene...@lists.openfabrics.org Subject: [ewg] OFED (EWG) meeting agenda for today (Feb 23) Hi All, Due to unexpected thing I cannot attend the meeting today :-( I sent a mail to Gopal asking him to replace me but got no respond yet. If he can't maybe Woody or Betsy can In any case - these are the items that should be covered: a. OFED 1.4.1 release: 1. SLES 11 - backport progress - Jeff Becker 2. Open MPI 1.3.1 - Jeff Squyres 3. RDS with iWARP support - Steve Wise 4. NFS/RDMA backports - at least to RH 5.2/3 - Steve Wise 5. Critical bugs: 1287maj RHELja...@mellanox.co.il IPoIB datagram mode initial packet loss 1516cri RHELandy.gro...@oracle.com Kernel panic on RHAS4.x loading RDS Note: There is 1.4.1 release number in bugzilla - please change bug release number to 1.4.1 if you wish it to be fixed for OFED 1.4.1 b. Open discussion 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
[ewg] ***SPAM*** OFED Minutes: 02/23/09
These are the OFED (EWG) meeting minutes for Feb 23 on OFED 1.4.1 release Meeting Summary: == 1. Update on 1.4.1. 2. Update on 1.4.1. PRs 3. Update on Sonoma agenda Details: == 1. Update on 1.4.1.: 1. SLES 11 - backport progress - Jeff Becker Just received access to RC4 source and started to build on Sunday Basic IB builds without change. MTHCA builds Connect-X next... Followed by ULPs 2. Open MPI 1.3.1 - Jeff Squyres 1.3.1 had not been released yet. Weekly Open MPI on Tuesdays Could release in 1 or 2 days if things go well Will send email and upload to Vlad 3. RDS with iWARP support - Steve Wise All of the latest updates pushed. Will begin testing with Oracle this week. CRTEST on 4 node cluster. Testing normally takes a couple of weeks Rupert asked about updating test plans for April event Steve will try to supply some info. Some tests are in OFED release May have to go to Oracle directly for other tests 4. NFS/RDMA backports - at least to RH 5.2/3 - Steve Wise 2.6.25 2.6.22 backports pass basic tests. Will try to push changes out this week RedHat 5.2: Most tests passing. Will push after .25 and .26 RedHat 5.3: In queue behind Redat 5.2 Rupert asked for tests on this these changes also 2. Update on 1.4.1. PRs 1287 majRHEL ja...@mellanox.co.ilmailto:ja...@mellanox.co.il IPoIB datagram mode initial packet loss No one on the call to respond to this issue 1516 cri RHEL andy.gro...@oracle.commailto:andy.gro...@oracle.com Kernel panic on RHAS4.x loading RDS No one on the call to address this either. Was told that Andy will be pinged and asked to respond Numerous PRs are still listed in Bugzilla as Blocking or Critical. John asked all participants to look at the PRs assigned to them and adjust their status as appropriate. 3. Sonoma updates from Bill Boas: Still struggling to get attendees and speakers Hope to extend early bird discounts into early May A side conversation stated at this point which diverted off into general issues/wishlist for OFED as well as other topics to be discussed at Sonoma. I will not capture the details of those discussions here. Rupert reminded everyone of the UNH/IHL testing of OFED 1.4.1 the week of March 16-20 and pushed us to have as many patches in place at that time as possible. John Russo [cid:image001.jpg@01C995CD.366283B0] __ John F. Russo Manager, Engineering QLogic Corporation 780 Fifth Avenue, Suite 140 King of Prussia, PA 19406 Direct: 610-233-4866 Main: 610-233-4800 Fax: 610-233-4777 Cell: 610-246-9903 Email: john.ru...@qlogic.commailto:john.ru...@qlogic.com www.qlogic.comhttp://www.qlogic.com True success is the undeniable truth that we have proved ourselves. -Joe Luppino-Esposito inline: image001.jpg___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] RE: RHEL 5.3 and OFED 1.4.x
I understand but I think that this is another consideration that should be factored in. Even if there are no critical PRs to fix, the introduction of RHEL 5.3 (along with less critical PRs) may be enough justification. I simply want to plant the seed in everyone's mind before our next meeting. Thanks -Original Message- From: Woodruff, Robert J [mailto:robert.j.woodr...@intel.com] Sent: Thursday, January 22, 2009 3:44 PM To: John Russo; gene...@lists.openfabrics.org Cc: ewg@lists.openfabrics.org Subject: RE: RHEL 5.3 and OFED 1.4.x In the last EWG meeting, we discussed waiting a month or so and seeing what kind of bugs were reported against 1.4 to determine if a 1.4.1 release was needed. From: general-boun...@lists.openfabrics.org [mailto:general-boun...@lists.openfabrics.org] On Behalf Of John Russo Sent: Thursday, January 22, 2009 12:37 PM To: gene...@lists.openfabrics.org Subject: [ofa-general] RHEL 5.3 and OFED 1.4.x Does the release of RHEL 5.3 create any additional justification for a maintenance release of OFED (1.4.1) to be generated? I am already hearing requests for an OFED release that will support it. John Russo QLogic ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] RE: [ofa-general] RE: Agenda for the OFED meeting today (Jan 5, 09)
Sorry Jeff... I am playing middle man with another engineer here for this information... The query does not have to be per QP, but it does need to be per IB HCA port to IB HCA port communication path. For example, if a node has 64 CPUs, it could do the query once per each other node on behalf of the 64 processes. Its still an N^2 set of queries, but at least N can be reduced to be the number of end node IB ports as opposed to the number of processes. -Original Message- From: Jeff Squyres [mailto:jsquy...@cisco.com] Sent: Monday, January 05, 2009 12:07 PM To: John Russo Cc: Tziporet Koren; ewg@lists.openfabrics.org; gene...@lists.openfabrics.org Subject: Re: [ofa-general] RE: Agenda for the OFED meeting today (Jan 5, 09) Hmm. Perhaps I'm not grokking your answer -- did you answer my question? I'm indirectly asking about scalability of the SM to have hundreds/thousands of MPI processes simultaneously querying the SM. On Jan 5, 2009, at 11:47 AM, John Russo wrote: When using routing algorithms such as lash, the SL used per end to end connection will vary based on the route. lash uses multiple VLs to avoid credit loops. As such the SL reported will vary based on fabric topology and which pair of end nodes the path is being requested on behalf of. -Original Message- From: Jeff Squyres [mailto:jsquy...@cisco.com] Sent: Monday, January 05, 2009 11:39 AM To: John Russo Cc: Tziporet Koren; ewg@lists.openfabrics.org; gene...@lists.openfabrics.org Subject: Re: [ofa-general] RE: Agenda for the OFED meeting today (Jan 5, 09) Would all MPI processes need to query the SM for each path that they want to use in a QP? On Jan 5, 2009, at 11:31 AM, John Russo wrote: Another suggestion for 1.5 Implementation of SA queries for Path Records (using IBTA 1.2.1 ServiceId field) in all OFED ULPs, especially for MPI The IBTA standard defines that the proper way to establish a connection is to get a PathRecord from the SM/SA and use it to define all the attributes of the communication path. Ideally the IBTA CM should then be used to establish the connection and QPs as well. At present, openmpi, mvapich1 and mvapich2 do not use PathRecords, but instead hard code attributes like the PKey, SL, etc. In some cases these hardcoded values can be overridden by configurable values such as PKey and SL, but such values must be uniform across all connections and must be provided per job (which can be error prone/tedious). At present opensm supports PKeys and SLs, however MPI cannot easily use these features. Other features, such as lash routing, in opensm do not work properly with MPI because the SL must be uniform across all connections, but for lash it will vary per route. Additionally, applications which do not use PathRecords will have difficulties with advanced features like IB routing, partitioning, etc. All of which are available or being worked on in opensm. From: ewg-boun...@lists.openfabrics.org [mailto:ewg-boun...@lists.openfabrics.org ] On Behalf Of Tziporet Koren Sent: Monday, January 05, 2009 1:00 AM To: ewg@lists.openfabrics.org Cc: gene...@lists.openfabrics.org Subject: [ewg] Agenda for the OFED meeting today (Jan 5, 09) Hello all, I hope we all had nice holidays and vacations, and now it's the time to get back to business. Agenda for OFED meeting today: 1. Conclusions from OFED 1.4 release: Open discussion 2. Do we wish to have OFED 1.4.: Please send pros cons before the meeting 3. OFED 1.5: Schedule and features. This is what we presented in SC08 about 1.5: Preliminary Schedule: * Feature Freeze: 3/20/09 * Alpha Release: 3/20/09 * Beta Release: 4/20/09 * RC1: 5/5/09 * RC2-RCx: About every 2 weeks as needed * Release: June 2009 Features: * Kernel.org: 2.6.28 and 2.6.29 * Multiple Event Queues to support Multi-core CPUs * NFS/RDMA - GA * RDS support for iWARP * OpenMPI 1.3 * Add support/backports for RedHat EL 5.3 and EL 4.8, SLES 11 * Support for Mellanox vNIC (EoIB) and FCoIB with BridgeX device * more TBD... We also presented the OS matrix but I suggest we will close this in the next meeting. My proposal: * Have the release in July and not June - so we will have more time for development * Stick to one kernel version base and not change in the middle since we saw that changing the kernel base caused a delay. We need to decide in the meeting if it is 2.6.29 or we should wait for 2.6.30. * Add IB over Eth - this is similar to iWARP but more like IB (e.g. including UD), and can work over ConnectX. Please send your suggestions to the list before the meeting if possible Tziporet ___ general mailing list gene...@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please
[ewg] RE: [ofa-general] RE: Agenda for the OFED meeting today (Jan 5, 09)
When using routing algorithms such as lash, the SL used per end to end connection will vary based on the route. lash uses multiple VLs to avoid credit loops. As such the SL reported will vary based on fabric topology and which pair of end nodes the path is being requested on behalf of. -Original Message- From: Jeff Squyres [mailto:jsquy...@cisco.com] Sent: Monday, January 05, 2009 11:39 AM To: John Russo Cc: Tziporet Koren; ewg@lists.openfabrics.org; gene...@lists.openfabrics.org Subject: Re: [ofa-general] RE: Agenda for the OFED meeting today (Jan 5, 09) Would all MPI processes need to query the SM for each path that they want to use in a QP? On Jan 5, 2009, at 11:31 AM, John Russo wrote: Another suggestion for 1.5 Implementation of SA queries for Path Records (using IBTA 1.2.1 ServiceId field) in all OFED ULPs, especially for MPI The IBTA standard defines that the proper way to establish a connection is to get a PathRecord from the SM/SA and use it to define all the attributes of the communication path. Ideally the IBTA CM should then be used to establish the connection and QPs as well. At present, openmpi, mvapich1 and mvapich2 do not use PathRecords, but instead hard code attributes like the PKey, SL, etc. In some cases these hardcoded values can be overridden by configurable values such as PKey and SL, but such values must be uniform across all connections and must be provided per job (which can be error prone/tedious). At present opensm supports PKeys and SLs, however MPI cannot easily use these features. Other features, such as lash routing, in opensm do not work properly with MPI because the SL must be uniform across all connections, but for lash it will vary per route. Additionally, applications which do not use PathRecords will have difficulties with advanced features like IB routing, partitioning, etc. All of which are available or being worked on in opensm. From: ewg-boun...@lists.openfabrics.org [mailto:ewg-boun...@lists.openfabrics.org ] On Behalf Of Tziporet Koren Sent: Monday, January 05, 2009 1:00 AM To: ewg@lists.openfabrics.org Cc: gene...@lists.openfabrics.org Subject: [ewg] Agenda for the OFED meeting today (Jan 5, 09) Hello all, I hope we all had nice holidays and vacations, and now it's the time to get back to business. Agenda for OFED meeting today: 1. Conclusions from OFED 1.4 release: Open discussion 2. Do we wish to have OFED 1.4.: Please send pros cons before the meeting 3. OFED 1.5: Schedule and features. This is what we presented in SC08 about 1.5: Preliminary Schedule: * Feature Freeze: 3/20/09 * Alpha Release: 3/20/09 * Beta Release: 4/20/09 * RC1: 5/5/09 * RC2-RCx: About every 2 weeks as needed * Release: June 2009 Features: * Kernel.org: 2.6.28 and 2.6.29 * Multiple Event Queues to support Multi-core CPUs * NFS/RDMA - GA * RDS support for iWARP * OpenMPI 1.3 * Add support/backports for RedHat EL 5.3 and EL 4.8, SLES 11 * Support for Mellanox vNIC (EoIB) and FCoIB with BridgeX device * more TBD... We also presented the OS matrix but I suggest we will close this in the next meeting. My proposal: * Have the release in July and not June - so we will have more time for development * Stick to one kernel version base and not change in the middle since we saw that changing the kernel base caused a delay. We need to decide in the meeting if it is 2.6.29 or we should wait for 2.6.30. * Add IB over Eth - this is similar to iWARP but more like IB (e.g. including UD), and can work over ConnectX. Please send your suggestions to the list before the meeting if possible Tziporet ___ 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
[ewg] RE: Agenda for the OFED meeting today (Jan 5, 09)
Another suggestion for 1.5 Implementation of SA queries for Path Records (using IBTA 1.2.1 ServiceId field) in all OFED ULPs, especially for MPI The IBTA standard defines that the proper way to establish a connection is to get a PathRecord from the SM/SA and use it to define all the attributes of the communication path. Ideally the IBTA CM should then be used to establish the connection and QPs as well. At present, openmpi, mvapich1 and mvapich2 do not use PathRecords, but instead hard code attributes like the PKey, SL, etc. In some cases these hardcoded values can be overridden by configurable values such as PKey and SL, but such values must be uniform across all connections and must be provided per job (which can be error prone/tedious). At present opensm supports PKeys and SLs, however MPI cannot easily use these features. Other features, such as lash routing, in opensm do not work properly with MPI because the SL must be uniform across all connections, but for lash it will vary per route. Additionally, applications which do not use PathRecords will have difficulties with advanced features like IB routing, partitioning, etc. All of which are available or being worked on in opensm. From: ewg-boun...@lists.openfabrics.org [mailto:ewg-boun...@lists.openfabrics.org] On Behalf Of Tziporet Koren Sent: Monday, January 05, 2009 1:00 AM To: ewg@lists.openfabrics.org Cc: gene...@lists.openfabrics.org Subject: [ewg] Agenda for the OFED meeting today (Jan 5, 09) Hello all, I hope we all had nice holidays and vacations, and now it's the time to get back to business. Agenda for OFED meeting today: 1. Conclusions from OFED 1.4 release: Open discussion 2. Do we wish to have OFED 1.4.: Please send pros cons before the meeting 3. OFED 1.5: Schedule and features. This is what we presented in SC08 about 1.5: Preliminary Schedule: * Feature Freeze: 3/20/09 * Alpha Release: 3/20/09 * Beta Release: 4/20/09 * RC1: 5/5/09 * RC2-RCx: About every 2 weeks as needed * Release: June 2009 Features: * Kernel.org: 2.6.28 and 2.6.29 * Multiple Event Queues to support Multi-core CPUs * NFS/RDMA - GA * RDS support for iWARP * OpenMPI 1.3 * Add support/backports for RedHat EL 5.3 and EL 4.8, SLES 11 * Support for Mellanox vNIC (EoIB) and FCoIB with BridgeX device * more TBD... We also presented the OS matrix but I suggest we will close this in the next meeting. My proposal: * Have the release in July and not June - so we will have more time for development * Stick to one kernel version base and not change in the middle since we saw that changing the kernel base caused a delay. We need to decide in the meeting if it is 2.6.29 or we should wait for 2.6.30. * Add IB over Eth - this is similar to iWARP but more like IB (e.g. including UD), and can work over ConnectX. Please send your suggestions to the list before the meeting if possible Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Panel at SC08/Austin -- what can we do about this?
This may be a small part of a larger issue. As the Open Fabrics products gain a larger customer base, we cannot assume that all users will be actively following the mailing lists. A detailed Users Guide which covers issues such as installation as well as the features and use of each ULP is necessary forthose who are not intimately familiar with the OFED/WinOF offerings. In addition, there is currently no documentation that informs anyone of changes between releases of OFED/WinOF. Even those who are working to test release candidates do not have enough information as to what has changed between builds. In order to build a legitimate set of user documentation, there needs to be a more formal process for developers to document changes, enhancements and bug fixes that are added to a release. This does not have to be a major burden on the developers; a few comments in a pre-determined README file would go a long way to improving communication of changes to the product. This would ensure that the community adequately tests updates to the products and that end-users would have the information they need to get the most out of it. Just my 2-cents. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan, Jim Sent: Saturday, November 22, 2008 5:41 PM To: Hebenstreit, Michael; ewg@lists.openfabrics.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [ewg] RE: Panel at SC08/Austin -- what can we do about this? I'm not completely clear about the genesis of the email below and the points that were made, but I thought this was extremely interesting. Maybe I'm unreasonably impressed because I got similar questions from people stopping by the OpenFabrics booth at SC'08. Just, as one example, a professor at The University of Tokyo asked for a programming manual, which I understood to mean a how-to-get-started document for implementing high-performance networks I'm copying the Marketing Working Group of OFA and will do so further to see if there's someone who can act on these concerns. I think ignorance of basics is a major challenge for OFA to address for broader acceptance of the interconnects we support Thanks, Jim Ryan From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hebenstreit, Michael Sent: Friday, November 21, 2008 3:10 PM To: ewg@lists.openfabrics.org Subject: [ewg] Panel at SC08/Austin At the session I raised points about missing documentation and was askled to summarize my ideas and write it to this list. specifically I would like to see a) a PDF binder of all mans/docs already available in the distribution on the web site b) a howto start with OFED (example: a collegue of mine had no idea that he needs a running opensm ...) c) for each special feature like ipoib, sdp, opensm... one or two pages describing WHAT the technology want's to achieve, plus some examples how it is used; how to enable/configure it d) on technologies like VERB/DAPL/...: one or two pages describing WHAT the technology want's to achieve, plus some examples how it is used; a few simple examples how to program with the libraries (at the level of a MPI introduction) best regards Michael Michael Hebenstreit Senior Cluster Architect Intel Corporation Software and Services Group/DRD 2800 N Center Dr, DP3-307 Tel.: +1 253 371 3144 WA 98327, DuPont UNITED STATES E-mail: [EMAIL PROTECTED] ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] Dependencies in OpenSM libraries
The concern is that use of basic utilities and diagnostic tools should not require opensm to be installed. Given the previous discussion it would have seemed that only opensm was going to use the non-public libraries. We are unclear on what the permitted scope of use of these libraries are. -Original Message- From: Sasha Khapyorsky [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 5:41 PM To: John Russo Cc: ewg@lists.openfabrics.org Subject: Re: [ewg] Dependencies in OpenSM libraries Hi John, On 14:12 Mon 22 Sep , John Russo wrote: A while back we discussed various dependencies on opensm libraries which were going to become non-public Was that intended to occur in 1.4 or later versions of OFED? In 1.4 I noticed that ibutils and infiniband-diags still have a dependency on libopensm.so and other opensm-libs supplied files. Is this a mistake or something planned to be resolved in a later release of OFED (1.5, etc). I don't think it is mistake - what is the issue with infiniband-diags using opensm-libs? Sasha ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Dependencies in OpenSM libraries
A while back we discussed various dependencies on opensm libraries which were going to become non-public Was that intended to occur in 1.4 or later versions of OFED? In 1.4 I noticed that ibutils and infiniband-diags still have a dependency on libopensm.so and other opensm-libs supplied files. Is this a mistake or something planned to be resolved in a later release of OFED (1.5, etc). __ John F. Russo Manager, Engineering QLogic Corporation 780 Fifth Avenue, Suite 140 King of Prussia, PA 19406 Direct: 610-233-4866 Main: 610-233-4800 Fax: 610-233-4777 Cell: 610-246-9903 Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] www.qlogic.com http://www.qlogic.com True success is the undeniable truth that we have proved ourselves. -Joe Luppino-Esposito image001.jpg___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] STOP the onslaught of EWG spam
Thank you. I was getting hammered during that same time. I had well over 800 emails. From: [EMAIL PROTECTED] on behalf of Jeff Squyres Sent: Sun 8/17/2008 8:21 AM To: OpenFabrics EWG; OpenFabrics General Subject: [ewg] STOP the onslaught of EWG spam The EWG list has gotten spam bombed over the last few hours. I lost count at 500+ spams in my inbox. I therefore logged into openfabrics.org and changed the site-wide password for Mailman (I have notified Jeff Becker of the new password). I then changed the EWG list to silently discard all non- member posts. Since I didn't know if other OF lists were being spam- bombed, I did the same for all OF lists as well. The spam onslaught has now stopped. I also notice that our mailmain installation is hopelessly out of date; it's v2.1.5 and the current version (including several important security fixes since v2.1.5) is v2.1.11. Someone needs to fix this ASAP. -- Jeff Squyres Cisco Systems ___ 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] Compatibility in OFED
QLogic is going to deal with the problem by working to decouple ourselves from this particular library. I initially raised the point as a general heads-up that there was at least one case where tools were broken because of a library change. The community needs to understand that not every user of the OFED offering is going to be monitoring the threads and any change that 'breaks' a user's script etc. will cause some backlash. -Original Message- From: Sasha Khapyorsky [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 9:34 AM To: Betsy Zeller Cc: John Russo; ewg@lists.openfabrics.org Subject: Re: [ewg] Compatibility in OFED On 01:04 Tue 03 Jun , Sasha Khapyorsky wrote: Separately, we should discuss how me manage version changes - introducing a version change in the middle of the RCs seems a bit late in the process. I agree that number of changes (at all) should be minimized in RC period. BTW the change you are complaining about was done Jun 13 2007. I think it was even before OFED-1.3 started. Sasha ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Compatibility in OFED
In OFED 1.3rc2 we noticed that libosmcomp's version had changed from 1 to 2. Unfortunately this has caused forward compatibility problems for existing applications which were compiled against OFED 1.2.5.1. It would be preferred if when such upgrades occur, both the .1 and .2 version of the library are provided such that existing applications do not need to be recompiled nor reinstalled. Alternatively limiting the necessity for such library version changes (never break old interfaces) would be preferred. For future OFED releases I would like to request that a libosmcomp.so.1 version of the library also be included. I realize that this issue is a bit dated (pre GA of 1.3) but I am bringing it up in hopes of avoiding similar issues in the future. __ John F. Russo Manager, Engineering QLogic Corporation 780 Fifth Avenue, Suite 140 King of Prussia, PA 19406 Direct: 610-233-4866 Main: 610-233-4800 Fax: 610-233-4777 Cell: 610-246-9903 Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] www.qlogic.com http://www.qlogic.com True success is the undeniable truth that we have proved ourselves. -Joe Luppino-Esposito image001.jpg___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] Re: [PATCH 0/5 VNIC] VNIC patch series for OFED-1.2andOFED-1.2.c
Either one RPM per ULP, defined directories and/or naming conventions would work. Either that or make it simple for each vendor to take the base OFED stack and plug in their own ULPs for their own customer base. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hal Rosenstock Sent: Tuesday, August 07, 2007 1:02 PM To: Lakshmanan, Madhu Cc: [EMAIL PROTECTED]; ewg@lists.openfabrics.org Subject: Re: [ewg] Re: [PATCH 0/5 VNIC] VNIC patch series for OFED-1.2andOFED-1.2.c Madhu, On 8/7/07, Lakshmanan, Madhu [EMAIL PROTECTED] wrote: From: Tziporet Koren [mailto:[EMAIL PROTECTED] To: Lakshmanan, Madhu Cc: Michael S. Tsirkin; Kuchimanchi, Ramachandra; [EMAIL PROTECTED]; ewg@lists.openfabrics.org Subject: Re: [ewg] Re: [PATCH 0/5 VNIC] VNIC patch series for OFED-1.2 andOFED-1.2.c Lakshmanan, Madhu wrote: Here's how I understand it: 1.2 should not see any development - it's a major bugfix only branch. 1.2.c is 1.2 code updated to kernel 2.6.22 plus bugfixes. 1.3 is 1.2.c updated to latest kernel (currently 2.6.23) plus new features. -- MST Thanks for the clarification, which I take to be the official EWG position. If I recall correctly, the decision to do away with a 1.2.1 release, and go with only a 1.2.c release, was made only a few days ago. The decision to have 1.2.c only was taken last week on Monday and was sent in the meeting summary. Features list of 1.2.c was closed and till yesterday no one from Qlogic requested any change in VNIC. In addition to the support for the ipath device and the EVIC (next generation Ethernet Virtual I/O Controller), these patches also fix bugs that we discovered when testing with the OFED 1.2.c releases and the ConnectX HCA. I suggest you prepare patches with bug fixes only for VNIC for 1.2.c and we will be able to insert them. Tziporet We'll submit new VNIC features into OFED 1.3. One other comment as to VNIC and OFED 1.3 which was brought up a while ago but never resolved: Since VNIC is a generic term and other vendors are likely to be submitting VNICs, there should be some vendor specific naming scheme with vendor like ql_ prepended to file names, etc. or in a vendor based ulp directory like ulp/qlogic. Maybe there are other ways to accomodate this as well. I think this needs to be done prior to an upstream push. Is that intended in the 1.3 timeframe ? Thanks. -- Hal Is there a final date till which you are accepting bug fixes for OFED 1.2.c? Thanks, Madhu ___ 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
