>> The primary problem I've had with ib2slurm is that it segfaults. There's a
>> bug in the ibnetdiscover library -- ib2slurm passes a NULL config pointer to
>> the ibnd_discover_fabric() which is supposed to be okay according to the
>> documentation, but that function actually requires a config structure to be
>> passed to it.
>>
>>
>> I've forked and updated ib2slurm:
>>
>>
>> https://github.com/jtfrey/ib2slurm
>>
>>
>> There doesn't appear to be much movement on the original project, so I
>> haven't put in a pull request against my fork.
>
> It's great that you try to revive the outdated ib2slurm project! The Slurm
> pages on topology.conf should point to your project in stead of the seemingly
> dead ib2slurm.
>
> That said, the concept of ib2slurm seems to be that you use ibnetdiscover to
> generate a cache file which is subsequently parsed by ib2slurm. My
> slurmibtopology.sh script uses the same idea: Parse the output from
> ibnetdiscover and generate a topology.conf file. For me personally it was
> easier to use awk than C for this task because awk supports associative
> arrays.
>
> /Ole
Thanks. The original ib2slurm wasn't able to export SLURM-style compacted
hostlists. Rather than implementing that myself, I've opted to (optionally)
link ib2slurm against libslurm and make use of SLURM's native hostlist
functionality to handle the compaction. Also added a CMakeLists.txt so that
CMake builds should be possible. All are present on the github repo.
https://github.com/jtfrey/ib2slurm
> use ibnetdiscover to generate a cache file which is subsequently parsed by
> ib2slurm
ib2slurm uses the same library functions that the ibnetdiscover utility uses.
Primarily, it produces an in-memory representation of the network topology.
For large networks or situations where a topology is routinely gathered and
cached using the ibnetdiscover library, the cache file can be reused by
ib2slurm. Otherwise, ib2slurm must walk the network to produce the in-memory
topology each time (and that can be slow, especially if you're trying to get a
node name mapping file debugged).
::::::::::::::::::::::::::::::::::::::::::::::::::::::
Jeffrey T. Frey, Ph.D.
Systems Programmer V / HPC Management
Network & Systems Services / College of Engineering
University of Delaware, Newark DE 19716
Office: (302) 831-6034 Mobile: (302) 419-4976
::::::::::::::::::::::::::::::::::::::::::::::::::::::
