common/ucx: New UCX common folder to be shared among components

[alex--m]

No description provided.

[ompiteam-bot]

Can one of the admins verify this patch?

[yosefe]

@alex--m according to openucx@43ec4cb, would it be correct to say that the only thing that UCC component uses from common UCX code is opal_common_ucx and its associated init/cleanup functions?

[alex--m]

@alex--m according to openucx@43ec4cb, would it be correct to say that the only thing that UCC component uses from common UCX code is opal_common_ucx and its associated init/cleanup functions?

@yosefe no, I wouldn't say that's accurate. The implementation in openucx@43ec4cb is just a temporary one, and I'd expect a full one would also use the datatype conversion functionality and free-lists in ompi_common_ucx (in addition to the stuff in opal_common_ucx you mentioned). Obviously, like with the UCP-worker reuse issue, using this kind of functionality would also require some UCC API before the UCC component could be finalized.

[yosefe]

@alex--m according to openucx@43ec4cb, would it be correct to say that the only thing that UCC component uses from common UCX code is opal_common_ucx and its associated init/cleanup functions?

@yosefe no, I wouldn't say that's accurate. The implementation in openucx@43ec4cb is just a temporary one, and I'd expect a full one would also use the datatype conversion functionality and free-lists in ompi_common_ucx (in addition to the stuff in opal_common_ucx you mentioned). Obviously, like with the UCP-worker reuse issue, using this kind of functionality would also require some UCC API before the UCC component could be finalized.

Ok so as we discussed on the confcall, the right way would be to 1st have the underlying UCC APIs that would be used by OpenMPI, and show how the OpenMPI code changes which make use of this API improve performance/memory usage/else.

[alex--m]

@alex--m according to openucx@43ec4cb, would it be correct to say that the only thing that UCC component uses from common UCX code is opal_common_ucx and its associated init/cleanup functions?

@yosefe no, I wouldn't say that's accurate. The implementation in openucx@43ec4cb is just a temporary one, and I'd expect a full one would also use the datatype conversion functionality and free-lists in ompi_common_ucx (in addition to the stuff in opal_common_ucx you mentioned). Obviously, like with the UCP-worker reuse issue, using this kind of functionality would also require some UCC API before the UCC component could be finalized.

Ok so as we discussed on the confcall, the right way would be to 1st have the underlying UCC APIs that would be used by OpenMPI, and show how the OpenMPI code changes which make use of this API improve performance/memory usage/else.

@shamisp is this what you got from the discussion last week? I seem to recall the decision was that Mellanox would review the non-UCC-related changes first, and only then we will proceed with any changes to UCC for OMPI components. If @yosefe 's version is right - we're at a deadlock again, since the UCC WG decided to wait for UCP changes first (see disucssion in this UCC PR ) - which makes sense as UCC relies on UCX and not vice versa.

[alex--m]

My bad - PR was misdirected, replaced with this one.