V4.0.x PML/UCX: don't do pml check during add_proc

[vspetrov]

V4.0.x of #8404

[jsquyres]

Please add the usual cherry-pick line in the commit message.

I.e., the same line as you get with git cherry-pick -x ... to get the commit from master.

Thanks!

[jsquyres]

The corresponding master PR (#8404) isn't merged yet. Converting back to Draft to make sure this PR isn't merged before #8404 is merged.

[vspetrov]

Please add the usual cherry-pick line in the commit message.

I.e., the same line as you get with git cherry-pick -x ... to get the commit from master.

Thanks!

@jsquyres it is not cherry-pick because master and v4.0.x diverged a bit. Do you mean, just add the similar line with master commit hash?

[jsquyres]

@vspetrov Ah, my mistake. If it's not a cherry pick, then you are absolutely correct that you should not list it as a cherry pick. But it probably would be good to cite the master hash/the general situation that occurred here, because -- at least on the surface -- the code change looks pretty similar between master and here, even if the surrounding code context is different. Cool?

[vspetrov]

@vspetrov Ah, my mistake. If it's not a cherry pick, then you are absolutely correct that you should not list it as a cherry pick. But it probably would be good to cite the master hash/the general situation that occurred here, because -- at least on the surface -- the code change looks pretty similar between master and here, even if the surrounding code context is different. Cool?

Do you want master hash in commit itself or the PR (in PR desc i'm referencing master PR) ? I can add master hash to commit once master PR is merged (to make sure commit does not change)

[jsquyres]

Putting it in the commit message would be great -- that helps when we have to go spelunking through the git log to figure out what happened / what commits got cherry-picked or otherwise pulled over to release branches, etc.

Thanks!

Don't forget to get these PRs reviewed; they can't be merged until they're reviewed.

Now that this is out of draft, I can dismiss the now-moot request for changes (because this is not technically a cherry pick).

[vspetrov]

what is needed for merge?

[hppritcha]

@vspetrov is this PR in response to a user reported problem, or perhaps the VASP performance thing? In any case we typically want to thank whoever noted the issue in the NEWS, hence the question.

[rhc54]

Might also want to re-run the problem application after #8408 is committed to see if it resolves the issue on its own.

[vspetrov]

@rhc54 i confirm that #8408 on its own fixes issue for given VASP repro.
@hppritcha regarding your question. The regression was discovered during Mellanox internal testing and was not reported by customer.

[gpaulsen]

@vspetrov Do you agree that we can now close this without merging?

[jladd-mlnx]

@gpaulsen this should be merged. The same issue would be present in v4.0.x. Val's fix was merged into v4.1.x.