<html><head></head><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:13px"><div id="yui_3_16_0_ym19_1_1513885044325_2938">OK, so slurm's libpmi2 is a functional superset of the libpmi2 provided by pmix 2.0+. That's good to know.</div><div id="yui_3_16_0_ym19_1_1513885044325_2939"><br></div><div id="yui_3_16_0_ym19_1_1513885044325_2940">My point here is that, if you use slurm's mpi/pmi2 plugin, regardless of which libpmi2 is installed, </div><div dir="ltr" id="yui_3_16_0_ym19_1_1513885044325_2941">slurm or pmix, you will always run the slurm pmi2 code since it is compiled directly into the plugin.</div> <div class="qtdSeparateBR"><br><br></div><div class="yahoo_quoted" style="display: block;"> <div style="font-family: Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 13px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"><font size="2" face="Arial"> On Wednesday, December 20, 2017 10:47 PM, "rhc@open-mpi.org" <rhc@open-mpi.org> wrote:<br></font></div> <br><br> <div class="y_msg_container"><div id="yiv8332649949"><div>On Dec 20, 2017, at 6:21 PM, Philip Kovacs <<a rel="nofollow" shape="rect" class="yiv8332649949" ymailto="mailto:pkdevel@yahoo.com" target="_blank" href="mailto:pkdevel@yahoo.com">pkdevel@yahoo.com</a>> wrote:<br clear="none" class="yiv8332649949"><div class="yiv8332649949yqt6011650997" id="yiv8332649949yqt32988"><div><blockquote class="yiv8332649949" type="cite"><br clear="none" class="yiv8332649949Apple-interchange-newline"><div class="yiv8332649949"><div class="yiv8332649949"><div class="yiv8332649949" style="background-color:rgb(255, 255, 255);"><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5702" style="">> -- slurm.spec: move libpmi to a separate package to solve a conflict with the<br clear="none" class="yiv8332649949" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5703"></div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5704" style="">> version provided by PMIx. This will require a separate change to PMIx as<br clear="none" class="yiv8332649949" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5705"></div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style="">> well.</div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style=""><br clear="none" class="yiv8332649949"></div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style="">I see the intention behind this change since the pmix 2.0+ package provides libpmi/libpmi2</div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style="">and there is a possible (installation) conflict with the Slurm implementation of those libraries. </div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style="">We've discussed that issue earlier.</div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style=""><br clear="none" class="yiv8332649949"></div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style="">Now, suppose a user installs the pmix versions of libpmi/pmi2 with the expectation that pmi</div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style="">calls will be forwarded to libpmix for greater speed, the so-called "backward compatibility" feature.</div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style=""><br clear="none" class="yiv8332649949"></div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style="">Shouldn't the Slurm mpi_pmi2 plugin attempt to link with libpmi2 instead of its internal </div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style="">implementation of pmi2? As it stands now, there won't be any forwarding of pmi2 code </div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style="">to libpmix which I imagine users would expect in that scenario.</div></div></div></div></blockquote></div></div><br clear="none" class="yiv8332649949"><div class="yiv8332649949">Sadly, it isn’t quite that simple. Most of the standard PMI2 calls are covered by the backward compatibility libraries, so things like MPICH should work out-of-the-box.</div><div class="yiv8332649949"><br clear="none" class="yiv8332649949"></div><div class="yiv8332649949">However, MVAPICH2 added a PMI2 extension call to the SLURM PMI2 library that they use and PMIx doesn’t cover (as there really isn’t an easy equivalent, and they called it PMIX_foo which causes a naming conflict), and so they would not work.</div><div class="yiv8332649949"><br clear="none" class="yiv8332649949"></div><div class="yiv8332649949"><br clear="none" class="yiv8332649949"></div></div></div><br><br></div> </div> </div> </div></div></body></html>