From raffenet at mcs.anl.gov Fri Aug 1 10:53:58 2014 From: raffenet at mcs.anl.gov (raffenet at mcs.anl.gov) Date: Fri, 1 Aug 2014 17:53:58 +0000 Subject: [OFIWG-MPI] Event Invitation: libfabric: MPI community feedback Message-ID: <4d36cc03-2585-438d-9159-7d85984fab50@NAGURSKI.anl.gov> Jeff Squyres (jsquyres) has invited you to libfabric: MPI community feedback -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 6069 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 6069 bytes Desc: not available URL: From sean.hefty at intel.com Fri Aug 1 17:03:42 2014 From: sean.hefty at intel.com (Hefty, Sean) Date: Sat, 2 Aug 2014 00:03:42 +0000 Subject: [OFIWG-MPI] Per the very end of the call today In-Reply-To: References: Message-ID: <1828884A29C6694DAF28B7E6B8A8237399D6F738@ORSMSX109.amr.corp.intel.com> > At the end of the call today, I mentioned that the dlsym-like mechanism for > getting vendor extensions could be a little tricky, depending on whether > the provider was linked inside libfabric. or whether it was dlopened > by libfabric.. > > Sean asked to see an example so that we could talk though it. > > After a little more thought, I realized that my assertion about it "being a > little tricky" is wrong. The dlsym-like mechanism should work exactly the > same, regardless of whether the provider is linked inside libfabric. > or is dynamically opened. I was thinking about this more, and I'm not sure that the functionality of dlsym is exactly what is wanted. Having the ability to open vendor-defined interfaces associated with a specific object is a better fit for the proposed model. For example, suppose someone defines a set of strided data transfer operations, which easily allows referencing every Nth item in an array. The API would be the same for all endpoint types, but the implementations would differ. dlsym would either need different names for different endpoint types, or the retrieved function would be forced to have branches in order to handle the different endpoints. I think a possible solution here is to define an open_if call as one of the base operations that all objects inherit. - Sean From jsquyres at cisco.com Fri Aug 8 09:09:27 2014 From: jsquyres at cisco.com (Jeff Squyres (jsquyres)) Date: Fri, 8 Aug 2014 16:09:27 +0000 Subject: [OFIWG-MPI] notes from MPI community feedback meeting today Message-ID: <1E4E3A8E-1947-4C50-BE1C-60AC6CCCAC7B@cisco.com> Thanks to all who attended. I'd like to re-iterate the closing thought: if you haven't looked at the libfabric APIs, please do so. **Now is the time to make comments / provide feedback*** Here's the notes I took from today: MPI community feedback on libfabric 8 Aug 2014 Attendees Jeff Squyres Jeff Hammond Sean Hefty Paul Grun Ryan Grant Ron Brightwell Alan Jea Antonio Pena Howard Pritchard Ken Raffenetti Michael Blocksome Nysal Jan Rolf vandeVaart Sameh Sharkawi Su Huang Howard: there's enough there in the prototype to do some playing around. Almost enough there for shmem (need some atomics) for verbs. Providers need to be aware that the other provider code in there is not sufficient -- e.g., PSM. E.g., from work at LANL, when you sit inside PSM inside libfabric, you won't necessarily have "smooth sailing". Calls to mind the want-everything vs. want-minimal tension in the MPI community. Jeff S: Can you explain? Howard: e.g., fault tolerance. Smooth sailing using verbs because they're low level. With PSM, you have no capability other than reset the whole job. JeffH: are you saying verbs is connection, PSM is connectionless. Howard: no. JeffH: are you saying PSM is just like sfi/libfabric? Are you saying PSM is bad? Howard: no. Just saying a warning signal. Just saying danger of vendors not providing some functionality from low level (e.g., PSM hides a lot). Although I do understand that this is a reference implementation, is not complete, etc. I don't see any gaping holes in the API, I just worry about what's going on under the covers. JeffH: PSM is just a reference implementation. The goal here is not to implement a new API on top of an old API, but rather to make a new API to replace the old API. So what we have today with PSM is just temporary. Howard: fair enough, but I guess with SFI PSM provider, all you have is matching sending/receiving. Sean: SFI is attempt to define these APIs, but the implementation is slow. The verbs provider doesn't support many of the SFI operations, too. There is a plan for a reference implementation that can expose any of the SFI APIs over sockets. It won't give the perf, but the functionality is there. Howard: the verbs one seems quite complete; I wish I had time to complete it. It all seems fine. My concern from the PSM provider is: where is that one going? I think the SFI API is convering well. I think we'll have something soon that we can kick the tires, and verbs seems closest yet. Paul: is your concern a problem with PSM a fundamental problem with PSM, or is it something that can be fixed? Howard: Hard to answer. If PSM provider is just showing RDM and tag matching, great. But we know from MPI that that isn't sufficient for MPI -- so what's the point? Sean: I think this is just a gap -- are these APIs good? Do we bother to implement them? There are plans to add more APIs (for PSM, I think Sean means), we're just adding implenentation as we go along. Howard: this actually makes me happy. Sean: we're just trying to figure out the target that we're shooting for. JeffS: do you mean the PSM provider / PSM API? Sean: we're working on providing more of the SFI APIs for PSM. And we're still looking at whether we have the right SFI APIs. We're not trying to expand PSM as an open source standard for these interfaces. We're trying to run over Intel's IB hardware that can fit under SFI APIs. Jeff: ok, enough PSM. What about from others? MPICH guys: we haven't had a chance to look at this stuff deeply yet. RonB: don't have an opinion yet. RyanG: so far, this looks quite reasonable. We could make it compatible with Portals. We could make a portals provider. The benefit is that you don't write directly to portals. There are enough APIs in SFI that you could get good portals support. Is the goal to make a uniform libfabric MPI? But we neeed to investigate more. Jeff: would you consider making a hardware provider that would be a peer to portals? RyanG: we are not developing hardware that will expose SFI interfaces. In that context, portals is a provider. E.g., you could make portals-compatible hw. Jeff: so why bother? If you're always targeting portals. We don't have any goal of making One MPI that sits on libfabric. RyanG: we just want to be compatible. JeffH: question -- I use RMA, but I don't use shmem much, just accumulate. Accumulate will be an active message. I haven't figured out how I would implement accumualte on SFI. Sean: probably couldn't easily answer. Can you describe the problem better? JeffH: accumulate must ship over a buffer and then do an accumulate onto an existing buffer (e.g., floating point). Best implementation on IBM systems/bluegene does a rendesvouz with a header that throws an interrupt which drives an active message, when then fires an active message read, do the accumulate, ...etc. (loop over for pipelining). Sean: atomics? JeffH: no, basically an RPC, but I would like it to not require polling. Sean: there are no active message APIs at this point. We've kept that open as something to look at, but nothing there yet. JeffH: ok, any thought on how one does one active AM API on top of SFI? Sean: AFI does define atomics from the MPI spec -- are these not sufficient? JeffH: but if I want to do an 8MB accumulate of doubles, I can do that with the atomics API? Sean: i.e., over 2M doubles? Yes. JeffH: 2M function calls, or 1 function call? Sean: depends on what the provider reports upwards. E.g., provider can report that it can do groups of 100. JeffH: is long double complex supported? Sean: thought the API yes, but depends on provider. Howard: ...missed. Sean: shows atomics APIs and enums. Types, operations, and function pointers. Howard: large one-sided / atomics are one use case, but there's also another use case of lots of small atomics -- might be more efficient to use the host processor (vs. the network/NIC). Itmight be quite difficult for a lot of hardware to native atomics. It might be better to do active message support and therefore more hardware can support it, and also provide the other model (e.g., lots of small atomics). JeffH: agree. Want to understand how these things compose w/ each other. E.g,. if accumulate is 1 double, I use the atomics API. But if I accumulate N doubles, I should use the active message API. How do I find the crossover? JeffS: absolute crossover is the route to madness. JeffH: no, I'm asking about ordering. Sean: shows ordering enums JeffH: what's the scope of those enums? Howard: if you queue up a send and then an AMO and then another send and then another AMO, is there a way to enforce ordering? Sean: from the perspective of the API, relax the API and let the app specify what the ordering constraints are. So if you mix sends and atomics, send-after-read/send-after-write (explaining enums on screen). E.g., a ...missed. All this is subject to the provider providing this functionality, of course. Also, additional fiels in fi_ep_attr -- ordering limitations based on the size. E.g., write-after-read and read-after-write may be based on the size. Howard: is there some what in the API to express that provider operates in cache-coherency domain of host processor? E.g., if atomics are coherent w.r.t. host processor, then ordering concerns go away. I don't remember what fi_write_coherent is. JeffH: good point. ARMCI and MPI have strict ordering consistency is critical. Sean: let the provider signal what it can do and let the app decide what it can do with it. The question is: does the API provide enough information to let the app decide what to do. JeffH: fi_ep_attr: 8 categories represented in FI_EP_ATTR, but only some of those in fi_ep_attr. What does this mean for send ordering max size? Sean: I added these later -- I should probably reconcile these two. Thanks. JeffH: concrete example -- Cray XE6 -- Gemini interconnect connected via hypertransport. There were some queries for ordering of writes between CPU load/store hitting HT and Gemini NIC hitting HT and what the actual consistency model is. This would determine whether MPI does X or Y optimization (e.g., how many mem barriers do you need)? Howard: you're regerring to HT ordering options in memory registration, right? ...aside: fi_write_coherent; this is probably what JeffH would need. JeffH: knowing cache coherence isn't enough. Howard: agreed. But there's at least 1 capability bit that's somewhat useful. JeffH: might be good to have similar SFI provider queries to what I described above (e.g., for other processors?), and may also determine where the network bolts into the memory controller / processor / etc. JeffS: Cisco's perspective: we don't like verbs, and are looking for a what about other vendors here? JeffS: Nvidia? Rolf: haven't kept on this... :-\ was kinda hoping this would be an overview. :-\ JeffS: IBM? MikeB: looks good. Had some questions about dynamic testing. Howard has talked about this a bit, though. But shared memory as a fabric -- is that expected to have a shared memory provider in libfabric? Or is that outside of libfabric? Also, what about collectives? I know the collective API is expected -- and it's important to MPI, but what if vendors have their own accelerators be exposed through libfabric? Sean: yes, plan is to have a shared memory provider. not there yet. For vendor specific additions, we want to have some kind of query the provider and get vendor-specific interfaces from the providers. Alan: shared memory provider. What if we want to use both? Do you have to use 2 different providers? Sean: probably yes. JeffS: what about shared memory provider and PSM in the same process -- can I figure out how to do the Right Thing? Sean: intent is yes, every provider will need to implement loopback. Depends on how the providers implement loopback. Sean: jeff can I see usnic direct before you publish it? might be useful to see what features you have defined, exposed, etc. JeffS: We're not ready to share yet, but it might be possible to share for the purpose of sharing ideas, etc. JeffS: thanks everyone -- please be sure to take time to look into this stuff if you have not already. EOM -- Jeff Squyres jsquyres at cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ From jsquyres at cisco.com Wed Aug 13 15:51:52 2014 From: jsquyres at cisco.com (Jeff Squyres (jsquyres)) Date: Wed, 13 Aug 2014 22:51:52 +0000 Subject: [OFIWG-MPI] FW: OFIWG Tuesday morning webex Message-ID: <1828884A29C6694DAF28B7E6B8A8237399DA01ED@ORSMSX109.amr.corp.intel.com> Topic: OFIWG: Tuesday morning Date: Tuesday, August 19, 2014 Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 206 650 477 Meeting Password: ofiwg ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?MTID=ma7f5577dcb7db9c7628dc081cb73e66d 2. Enter your name and email address. 3. Enter the meeting password: ofiwg 4. Click “Join Now”. To view in other time zones or languages, please click the link: https://cisco.webex.com/ciscosales/j.php?MTID=m77784f147874323c5e12893c3007c18b ---------------------------------------------------------------- ALERT – PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (408) OR (919) AREA CODES ---------------------------------------------------------------- Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 Dialing the WebEx toll free numbers from within 408 or 919 area codes is not enabled (non-Cisco phones). “ If you dial the toll-free numbers within the 408 or 919 area codes you will be instructed to hang up and dial the local access number.” Please use the call-back option whenever possible and otherwise dial local numbers only. The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/mc 2. On the left navigation bar, click “Support”. You can contact me at: jsquyres at cisco.com 1-408-525 0971 To update this meeting to your calendar program (for example Microsoft Outlook), click this link: https://cisco.webex.com/ciscosales/j.php?MTID=m7cf7a81a30187cdd83e1df5fb71b948c WebEx will automatically setup Meeting Manager for Windows the first time you join a meeting. To save time, you can setup prior to the meeting by clicking this link: https://cisco.webex.com/ciscosales/meetingcenter/mcsetup.php The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://cisco.webex.com/ciscosales/systemdiagnosis.php. http://www.webex.com CCP:+14085256800x206650477# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 5452 bytes Desc: not available URL: From jsquyres at cisco.com Wed Aug 13 15:52:05 2014 From: jsquyres at cisco.com (Jeff Squyres (jsquyres)) Date: Wed, 13 Aug 2014 22:52:05 +0000 Subject: [OFIWG-MPI] FW: OFIWG Tuesday afternoon webex Message-ID: <1828884A29C6694DAF28B7E6B8A8237399DA01F5@ORSMSX109.amr.corp.intel.com> Topic: OFIWG: Tuesday afternoon Date: Tuesday, August 19, 2014 Time: 1:00 pm, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 202 444 418 Meeting Password: ofiwg ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?MTID=m0530970b4f120747716a8641b865957e 2. Enter your name and email address. 3. Enter the meeting password: ofiwg 4. Click “Join Now”. To view in other time zones or languages, please click the link: https://cisco.webex.com/ciscosales/j.php?MTID=mc4a2544cf05fad158f0689365441f353 ---------------------------------------------------------------- ALERT – PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (408) OR (919) AREA CODES ---------------------------------------------------------------- Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 Dialing the WebEx toll free numbers from within 408 or 919 area codes is not enabled (non-Cisco phones). “ If you dial the toll-free numbers within the 408 or 919 area codes you will be instructed to hang up and dial the local access number.” Please use the call-back option whenever possible and otherwise dial local numbers only. The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/mc 2. On the left navigation bar, click “Support”. You can contact me at: jsquyres at cisco.com 1-408-525 0971 Add this meeting to your calendar program: https://cisco.webex.com/ciscosales/j.php?MTID=m69333b5df083e48d6c0f692138c3d128 The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://cisco.webex.com/ciscosales/systemdiagnosis.php. http://www.webex.com CCP:+14085256800x202444418# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 5152 bytes Desc: not available URL: From jsquyres at cisco.com Wed Aug 13 15:52:20 2014 From: jsquyres at cisco.com (Jeff Squyres (jsquyres)) Date: Wed, 13 Aug 2014 22:52:20 +0000 Subject: [OFIWG-MPI] FW: OFIWG Wednesday morning webex Message-ID: <1828884A29C6694DAF28B7E6B8A8237399DA01FF@ORSMSX109.amr.corp.intel.com> Topic: OFIWG: Wednesday morning Date: Wednesday, August 20, 2014 Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 207 625 456 Meeting Password: ofiwg ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?MTID=m61279fe2746a3e7c4732d1bad6d1b1ff 2. Enter your name and email address. 3. Enter the meeting password: ofiwg 4. Click “Join Now”. To view in other time zones or languages, please click the link: https://cisco.webex.com/ciscosales/j.php?MTID=ma06c27a9bf8074a951a453cf718befe2 ---------------------------------------------------------------- ALERT – PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (408) OR (919) AREA CODES ---------------------------------------------------------------- Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 Dialing the WebEx toll free numbers from within 408 or 919 area codes is not enabled (non-Cisco phones). “ If you dial the toll-free numbers within the 408 or 919 area codes you will be instructed to hang up and dial the local access number.” Please use the call-back option whenever possible and otherwise dial local numbers only. The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/mc 2. On the left navigation bar, click “Support”. You can contact me at: jsquyres at cisco.com 1-408-525 0971 Add this meeting to your calendar program: https://cisco.webex.com/ciscosales/j.php?MTID=m77152ad17609dbb27238cefe475ee283 The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://cisco.webex.com/ciscosales/systemdiagnosis.php. http://www.webex.com CCP:+14085256800x207625456# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 5154 bytes Desc: not available URL: From jsquyres at cisco.com Wed Aug 13 15:52:49 2014 From: jsquyres at cisco.com (Jeff Squyres (jsquyres)) Date: Wed, 13 Aug 2014 22:52:49 +0000 Subject: [OFIWG-MPI] FW: OFIWG Wednesday afternoon webex Message-ID: <1828884A29C6694DAF28B7E6B8A8237399DA0234@ORSMSX109.amr.corp.intel.com> Topic: OFIWG: Wednesday afternoon Date: Wednesday, August 20, 2014 Time: 1:00 pm, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 203 001 107 Meeting Password: ofiwg ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?MTID=m744fbfe0caa758a6ef21f8a991a86b09 2. Enter your name and email address. 3. Enter the meeting password: ofiwg 4. Click “Join Now”. To view in other time zones or languages, please click the link: https://cisco.webex.com/ciscosales/j.php?MTID=m3f63d9b6daddabc6ce5b3b1e800b3bef ---------------------------------------------------------------- ALERT – PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (408) OR (919) AREA CODES ---------------------------------------------------------------- Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 Dialing the WebEx toll free numbers from within 408 or 919 area codes is not enabled (non-Cisco phones). “ If you dial the toll-free numbers within the 408 or 919 area codes you will be instructed to hang up and dial the local access number.” Please use the call-back option whenever possible and otherwise dial local numbers only. The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/mc 2. On the left navigation bar, click “Support”. You can contact me at: jsquyres at cisco.com 1-408-525 0971 Add this meeting to your calendar program: https://cisco.webex.com/ciscosales/j.php?MTID=mb9d2657d603742a7d727ba57f2bbc0bc The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://cisco.webex.com/ciscosales/systemdiagnosis.php. http://www.webex.com CCP:+14085256800x203001107# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 5158 bytes Desc: not available URL: From sean.hefty at intel.com Wed Aug 20 18:24:23 2014 From: sean.hefty at intel.com (Hefty, Sean) Date: Thu, 21 Aug 2014 01:24:23 +0000 Subject: [OFIWG-MPI] creation of github ofiwg project Message-ID: <1828884A29C6694DAF28B7E6B8A8237399DB74D7@ORSMSX109.amr.corp.intel.com> For those who weren't at the OFIWG F2F, an ofiwg github project was created and the libfabric/fabtests git trees were moved from openfabrics.org to github. https://github.com/ofiwg/libfabric.git Github provides better support for a collaborative development effort. We still anticipate using the openfabrics.org server to host tarballs. - Sean