Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: Re: [hwloc-devel] upcoming hwloc v1.7
From: Brice Goglin (Brice.Goglin_at_[hidden])
Date: 2013-03-25 19:08:08

Le 22/03/2013 19:35, Samuel Thibault a écrit :
> Brice Goglin, le Thu 07 Mar 2013 23:59:54 +0100, a écrit :
>> We have a specific ABI field in the main component structure
>> (hwloc_component) to avoid problems in case we break this new ABI.
>> Breaking it isn't as bad as breaking the main hwloc ABI, but it'd still
>> be good to not break it in every major release anyway. If you see
>> anything to change to make things more future-proof, let me know, I'd
>> rather change it before v1.7.
> I'm wondering about the hwloc_disc_component_type_e values and excludes.
> AIUI, GLOBAL is supposed to exclude anything else, while CPU excludes
> with other CPUs, and ADDITIONAL isn't supposed to exclude with anything
> except GLOBAL. I hope I have made it clearer in the documentation.
> BTW, it seems we're not supposed to set multiple types in the type
> field; that might be a concern, I'd tend to see the type field as an OR
> of types.
> I'm wondering whether we should already introduce various types for the
> various additional plugins we already have: OpenCL, PCI, nvml, gl, cuda.
> I'd tend to reckon it makes sense to, so that third-party can already
> exclude them from their plugins, if they ever need to (better provide
> the feature than wait for people to ask for it next century).

(just replying to this since I applied your other comments).

I would rather wait and see what happens before adding specific types
for OPENCL, PCI, ... There won't be many third party plugins, and most
of them won't need any such conflict anyway (I don't expect
significantly different implementations of CUDA/NVML; other GL/OpenCL
implems should add other GPU vendor support instead of conflicting with

PCI is the most likely candidate for such a conflict. A PCI conflict
means that the platform supports both the "new" PCI discovery and our
libpci/libpciaccess, and that this new implementation isn't included in
a platform-specific GLOBAL component (like BGQ). We'll see when that

I'll keep things simple for now and we'll extend the plugin interface
later if really needed. I improved things a little bit to make it easier
to override an existing component with a third party plugin (use the
same name with a higher priority), and we still have the environment
variable to exclude things too.