January 2014 - devel - mailman3.cels.anl.gov

Webex info: MPI implementation requirements for a network layer
by Jeff Squyres (jsquyres) 13 Jan '14

13 Jan '14

Thanks to all who replied to the Doodle and emailed me feedback. Those who have not yet done so, please send me feedback by COB tomorrow (Tues, 14 Jan 2014). Per the Doodle, everyone is able to attend at 2pm US Eastern time, Wednesday, 15 Jan 2014. Webex info is below. I'm sending this notice to all the lists from which I initially requested feedback, and am also BCC'ing everyone who replied to the Doodle. But I do not have email addresses for the following Doodle responders -- can someone forward this mail to them? - Michael Blocksome - Chulho Kim - Michael Raymond - Shane Farmer Webex link: https://cisco.webex.com/ciscosales/j.php?ED=250656997&UID=0&PW=NMmMxZWU1NWZ… Password: mpi Complete webex info below See you Wednesday; thanks. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ **** You can forward this email invitation to attendees **** Jeff Squyres invites you to attend this online meeting. Topic: MPI implementation requirements for network layer Date: Wednesday, January 15, 2014 Time: 2:00 pm, Eastern Standard Time (New York, GMT-05:00) Meeting Number: 209 436 402 Meeting Password: mpi ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=250656997&UID=0&PW=NMmMxZWU1NWZ… 2. Enter your name and email address. 3. Enter the meeting password: mpi 4. Click "Join Now". To view in other time zones or languages, please click the link: https://cisco.webex.com/ciscosales/j.php?ED=250656997&UID=0&PW=NMmMxZWU1NWZ… ---------------------------------------------------------------- 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(a)cisco.com 1-408-525 0971 To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://cisco.webex.com/ciscosales/j.php?ED=250656997&UID=0&ICS=MI&LD=1&RD=… 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 tohttps://cisco.webex.com/ciscosales/systemdiagnosis.php. http://www.webex.com CCP:+14085256800x209436402# 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.

1 0

Re: [mpich-devel] [mpich-discuss] Use of Signed-off-by in MPICH
by Jed Brown 09 Jan '14

09 Jan '14

"Antonio J. Peña" <apenya(a)mcs.anl.gov> writes: > In our group meeting we decided to keep using the Signed-off-by field, > as it's more convenient for us. This has been clarified in our wiki page > on the workflow section: > https://wiki.mpich.org/mpich/index.php/Git#Overall_Workflow Cool, thanks for the update.

1 0

Re: [mpich-devel] [mpich-discuss] Use of Signed-off-by in MPICH
by "Antonio J. Peña" 09 Jan '14

09 Jan '14

In our group meeting we decided to keep using the Signed-off-by field, as it's more convenient for us. This has been clarified in our wiki page on the workflow section: https://wiki.mpich.org/mpich/index.php/Git#Overall_Workflow Thank you for bringing our attention to this. Toni On 01/05/2014 01:24 PM, Pavan Balaji wrote: > On Jan 5, 2014, at 11:59 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: >>> Essentially, itï¿½s what we define it to be. I guess we could have used >>> ï¿½Reviewed-byï¿½, but Iï¿½m not sure it really matters that much. >> FWIW, I think it's a needless deviation from a widespread convention. > Iï¿½ll bring this up at the next group meeting and see what the other developers think. > > ï¿½ Pavan > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > -- Antonio J. Peï¿½a Postdoctoral Appointee Mathematics and Computer Science Division Argonne National Laboratory 9700 South Cass Avenue, Bldg. 240, Of. 3148 Argonne, IL 60439-4847 apenya(a)mcs.anl.gov www.mcs.anl.gov/~apenya

1 0

Re: [mpich-devel] Weak symbols, clang, and users compiling with -fvisibility=hidden
by "Antonio J. Peña" 08 Jan '14

08 Jan '14

Let me discuss this with Ken. We'll get back to you. Antonio On 01/06/2014 06:19 PM, Jed Brown wrote: > Jed Brown <jedbrown(a)mcs.anl.gov> writes: > >> Pavan Balaji <balaji(a)mcs.anl.gov> writes: >>> This attribute is tested in configure before it’s added to mpi.h.in. >> Yes, the configure test is incorrect and the resulting usage in MPICH is >> broken (does not do what you intend). > As far as I know, > > #pragma weak MPI_Xyz = PMPI_Xyz > > is equivalent to what was intended with the attribute syntax > > __attribute__((weak, alias("PMPI_Xyz"))) > > (which belongs in an implementation file, not in the public header). Is > there a reason to bother testing for the attribute syntax? -- Antonio J. Peña Postdoctoral Appointee Mathematics and Computer Science Division Argonne National Laboratory 9700 South Cass Avenue, Bldg. 240, Of. 3148 Argonne, IL 60439-4847 apenya(a)mcs.anl.gov www.mcs.anl.gov/~apenya

1 0

MPI implementation requirements for low-layer network APIs
by Jeff Squyres (jsquyres) 08 Jan '14

08 Jan '14

Short version: ============== Sean Hefty from Intel is soliciting feedback from the MPI community about what MPI needs from a new low-level networking API (that hopes to be the successor to libibverbs). He has asked me to gather this feedback and present it to the OpenFabrics "libfabric" working group on January 21. Please a) unicast email to me what you would like to convey to this working group by COB next Tuesday (January 14), and/or b) sign up on the Doodle below to join a webex to review the collected feedback before I present it to the OpenFabrics working group. Due to the short turnaround, I picked several days at the end of next week: http://doodle.com/44uea5v38euu6smh More detail: ============ As some of you may already be aware, Sean Hefty at Intel is leading an effort in the OpenFabrics community to basically re-design the network layer API for userspace to talk directly with hardware. Sean has been presenting his vision of this new "libfabric" for a little while now; he even hosted a BOF about it at SC'13. You can think of it as "verbs 2.0", but it's really quite a bit more than that: a) it's starting the API over from scratch b) there's no implicit design requirements for InfiniBand c) there's no need to be API/ABI compatible with current generations of the libibverbs API One of the major explicit goals of libfabric is to support MPI well. Bad memory registration support is probably the easiest-to-discuss verbs complaint that we MPI developers have had over the years, but there are other areas where verbs is lacking, too. Now is the chance for us to voice MPI's requirements. Here's my plan: 1. I have many opinions in this area, and I know many of you do, too. Please send me your opinions and feedback in whatever format you'd prefer: - email/text - slides - word documents - pictures of whiteboards with notes - ...etc. NOTE: The OpenFabrics working group is basically assuming that we can all rattle off the tops of our heads what MPI wants (which is probably a good assumption), so please send your feedback by COB Tuesday, January 14, 2014. 2. I'll take all this feedback and assemble it into a cohesive story/set of slides. 3. I'll then host a webex late next week (signup on the Doodle so that we can find a time that works for the most people) to both go over the slides from the feedback received so far as well as solicit any further feedback from people on the call. http://doodle.com/44uea5v38euu6smh 4. Finally, I'll take the results of discussion from the webex and present the final slides to the OpenFabrics working group on Jan 21. Your input would be greatly appreciated. Many thanks for your time. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

pwrite/pread
by Rob Latham 07 Jan '14

07 Jan '14

In 2013 are there any platforms I should worry about that do not have pwrtie/pread ? ROMIO's already using them in the Lustre and XFS drivers, but those file systems are closely correlated to "modern" operating systems. ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-devel] Weak symbols, clang, and users compiling with -fvisibility=hidden
by Jed Brown 06 Jan '14

06 Jan '14

Jed Brown <jedbrown(a)mcs.anl.gov> writes: > Pavan Balaji <balaji(a)mcs.anl.gov> writes: >> This attribute is tested in configure before it’s added to mpi.h.in. > > Yes, the configure test is incorrect and the resulting usage in MPICH is > broken (does not do what you intend). As far as I know, #pragma weak MPI_Xyz = PMPI_Xyz is equivalent to what was intended with the attribute syntax __attribute__((weak, alias("PMPI_Xyz"))) (which belongs in an implementation file, not in the public header). Is there a reason to bother testing for the attribute syntax?

1 0

Re: [mpich-devel] [mpich-discuss] Use of Signed-off-by in MPICH
by Jed Brown 06 Jan '14

06 Jan '14

Michael Blocksome <blocksom(a)us.ibm.com> writes: > Furthermore, whether or not a cherry-pick is even needed depends on if the > "source" branch has been completely rebased to master or not. If not, > then the commit needs to be changed in the process of moving to master > (which resets the committer), but if it is a strict fast-forward of master > then the commit is not altered (committer remains the same) and the HEAD > pointer of master is merely moved to point to the new commit. This is not true with git cherry-pick, unless you explicitly pass --ff. > It seems to me that what you really don't like is the "rebase" style of > git workflow and would prefer a "merge" style instead? I like topic branches, but that is neither here nor there, and even with topic branches, the commit doesn't enter the repository (or doesn't start to be integrated) without discussion in which it acquires Reviewed-by/Acked-by tags (and Signed-off-by for projects using a DCO). > Whether some commit says "Signed-off" or "Reviewed" or > nothing is really not a big deal - as long as the convention is > documented by the community and followed. Not a big deal, just document it if you're going to use it differently than every other project. It's not my decision and it's not important to me; I only intended to point out the lack of documentation and the usage inconsistency relative to the intent of the Git developers and the convention used by thousands of developers of high-profile projects (influencing tooling and dominating search results).

1 0

Re: [mpich-devel] [mpich-discuss] Use of Signed-off-by in MPICH
by Michael Blocksome 06 Jan '14

06 Jan '14

What you've said is exactly why we add the "Signed-off by" clause. There are only two pieces of information and therefore all that gets retained is the first (author) and last (committer). Furthermore, whether or not a cherry-pick is even needed depends on if the "source" branch has been completely rebased to master or not. If not, then the commit needs to be changed in the process of moving to master (which resets the committer), but if it is a strict fast-forward of master then the commit is not altered (committer remains the same) and the HEAD pointer of master is merely moved to point to the new commit. If you are trying to have the commiter != author, then you'd have to mess around with the commit in this case. It seems to me that what you really don't like is the "rebase" style of git workflow and would prefer a "merge" style instead? There are advantages and disadvantages to both - which are well documented in flame wars all across the internet and don't need to be repeated here. Whether some commit says "Signed-off" or "Reviewed" or nothing is really not a big deal - as long as the convention is documented by the community and followed. Michael Blocksome Parallel Environment MPI Middleware Team Lead, TCEM POWER, x86, and Blue Gene HPC Messaging blocksom(a)us.ibm.com From: Jed Brown <jedbrown(a)mcs.anl.gov> To: Michael Blocksome/Rochester/IBM@IBMUS, Cc: devel(a)mpich.org Date: 01/06/2014 02:50 PM Subject: Re: [mpich-discuss] Use of Signed-off-by in MPICH Michael Blocksome <blocksom(a)us.ibm.com> writes: > In our workflow, often the commit is pushed to an ibm review branch, then > the signer (usually me) does a signed-off cherry-pick to an anl review > branch and pushes the code to mpich-ibm git repository for ANL to > integrate. Using "signed off by" is usually much easier than playing git > games to ensure that the author and committer are different. When you cherry-pick, rebase, or amend, Committer will be automatically reset; no "games". The problem with that is there are only two pieces of information (Author and Committer), so if Pavan (for example) cherry-picks from your branch, the semantic information that you were a middle-man would be lost [1]. If that semantic information is about review rather than IP, I would use Reviewed-by instead of Signed-off-by, but whatever the convention is/becomes, documentation and consistency is helpful. [1] If he merges from your branch instead of cherry-picking, then your commit does not get rewritten and his name would be on the merge commit. [attachment "attbohle.dat" deleted by Michael Blocksome/Rochester/IBM]

1 0

Re: [mpich-devel] [mpich-discuss] Use of Signed-off-by in MPICH
by Jed Brown 06 Jan '14

06 Jan '14

Michael Blocksome <blocksom(a)us.ibm.com> writes: > In our workflow, often the commit is pushed to an ibm review branch, then > the signer (usually me) does a signed-off cherry-pick to an anl review > branch and pushes the code to mpich-ibm git repository for ANL to > integrate. Using "signed off by" is usually much easier than playing git > games to ensure that the author and committer are different. When you cherry-pick, rebase, or amend, Committer will be automatically reset; no "games". The problem with that is there are only two pieces of information (Author and Committer), so if Pavan (for example) cherry-picks from your branch, the semantic information that you were a middle-man would be lost [1]. If that semantic information is about review rather than IP, I would use Reviewed-by instead of Signed-off-by, but whatever the convention is/becomes, documentation and consistency is helpful. [1] If he merges from your branch instead of cherry-picking, then your commit does not get rewritten and his name would be on the merge commit.

1 0