btl/uct: remove this from 4.0.x release branch

[hppritcha]

The UCX UCT layer is not really intended to be used outside
UCX itself. The OpenUCX community does not guarantee API
compatibility of the UCT layer between major releases.

we will leave the UCT BTL in master so it can be used for
experiments, etc. but will remove it from releases, at
least the 4.0.x release.

Fixes #6640

Signed-off-by: Howard Pritchard [email protected]

[jladd-mlnx]

👍

[jsquyres]

@hppritcha I strongly suggest you do not remove this component from the v4.0.x branch -- it will break our backwards compatibility guarantees.

Instead, I suggest two things:

1. Make this component's configure.m4 smarter to determine whether it can actually build or not (i.e., we should not get a compile error from btl/uct that blocks building the rest of OMPI).
2. Make this component not be the default at run time. I understand that no one wants to support it, but we did ship it in v4.0, so we can't just delete it in mid-4.0.x stream. But we can make it not run by default, I think.

Thoughts?

[bosilca]

@thananon

[jsquyres]

Please do not merge this PR. It will break our backwards compatibility guarantees.

[gpaulsen]

perhaps we can leave everything as-is, but add some configury to v4.0.x to disable building it by default.

[thananon]

I have no objection in removing it from 4.0.x but I just want to drop this here as a reference.

• Without btl/uct and btl/ofi, we kinda lost osc/rdma support too. I'm not sure if each PML have their one-sided API implemented.
• btl/uct is performing best in MT, even for two sided, by miles. If this get removed, when someone look for multithreaded support, we will have to point them to master instead.

[jsquyres]

We can't remove it from v4.0.x, and we should keep building it by default (if possible), because that's what we did in v4.0.0. Changing that in mid-stream of the v4.0.x release train is probably not a good idea (IMNSHO).

I'm personally in favor of the 2 recommendations I made above (#6643 (comment)). Other thoughts on that?

[rhc54]

I agree that it cannot be removed from v4.0.x, especially if it does function with at least some UCX versions and provides a performance benefit to boot. Seems to me that extending the configure logic to ensure it builds only with compatible UCX versions makes sense (along with something in the FAQ about supported versions), and it should remain as the default when it does build since that is the current priority. Question then becomes: who is going to do the configure update and the FAQ entry?