pml/cm: fix a problem introduced with cuda support

[hppritcha]

PR #8536 introduced a regression in non-cuda environments
when an application is using derived, but continguous datatypes.

Related to #8905.

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

[wckzhang]

Patch should be fine, but shouldn't opal_convertor_prepare_for_send be able to handle the use case?

[hppritcha]

looks like ompi jenkins is having problems cloning from github at the moment
bot:ompi:retest

[hppritcha]

@jsquyres any idea why the call to opal_convertor_prepare_for_send breaks things here? looks like it adds a bunch of additional overhead we don't want in any case when not using CUDA.

[jsquyres]

@jsquyres any idea why the call to opal_convertor_prepare_for_send breaks things here? looks like it adds a bunch of additional overhead we don't want in any case when not using CUDA.

I am not knowledgeable about the innards of DDT -- I think this is a question for @bosilca...

[bosilca]

What is the call to convertor_prepare_for_send breaking ? What I see in the patch is that if the datatype is contiguous then the convertor will not be properly initialized is CUDA support is not active. This can be perceived as a shortcut (saving one function call), because the data to be sent is contiguous of size count*data.size. I assume whoever wrote that code took care to properly accounting for the potential use of a lower bound in the datatype.

[hppritcha]

Jithin did some optimization work in #602 that introduced this bypass of opal_convertor_prepare_for_send or related code.
As it was, master was failing lots of IBM tests without this patch post merge of #8536

See hpc#42

I was also seeing this in MTT but had not been looking into the issue at that point.

[wckzhang]

Might as well encapsulate the MCA_PML_SWITCH_CUDA_CONVERTOR_OFF with the if statement as well. Doesn't make sense to call it otherwise.

[hppritcha]

@wckzhang reworked per your suggestion