[dmitrygx]

What

Select SL not depending on AR support by default.

Why ?

To align with previous behavior, since users may not expect that UCX selects SL with AR (if possible) or SL without AR (if possbile) after #5869.

How ?

1. Introduced new value for ucs_ternary_value_t - "auto" that select default value for ternary value.
2. Handled "auto" value when selecting SL. If "auto" is set, UCT/IB/MLX5 selects SL requested by a user (thru UCX_IB_SL=<sl>) or 0.
3. Updated UCT/IB gtests accordingly and fix bug when verifying OK case (some case wasn't handled, e.g. UCS_NO).

[dmitrygx]

@yosefe @brminich wdyt is the best option from the items below?

• having ucs_ternary_value_t with UCS_AUTO added
• rename ucs_ternary_value_t to ucs_ynta_velue_t (i.e. YNTA = { Yes, No, Try, Auto })

[brminich]

@yosefe @brminich wdyt is the best option from the items below?

• having ucs_ternary_value_t with UCS_AUTO added
• rename ucs_ternary_value_t to ucs_ynta_velue_t (i.e. YNTA = { Yes, No, Try, Auto })

Maybe add ucs_ynta_velue_t as a new type?

[yosefe]

Maybe add ucs_ynta_velue_t as a new type?

+1

[dmitrygx]

Maybe add ucs_ynta_velue_t as a new type?

+1

but, it will have the same UCS_YES/UCS_NO/UCS_TRY that are the same as for ucs_ternary_value_t

[brminich]

but, it will have the same UCS_YES/UCS_NO/UCS_TRY that are the same as for ucs_ternary_value_t

Yes, but you will not need to define/implement handling of "auto" for all existing ternary vars

[dmitrygx]

but, it will have the same UCS_YES/UCS_NO/UCS_TRY that are the same as for ucs_ternary_value_t

Yes, but you will not need to define/implement handling of "auto" for all existing ternary vars

they should have different names then

[yosefe]

they should have different names then

UCS_TERNARY_[YES|NO|TRY]
UCS_YNTA_[YES|NO|TRY|AUTO]

[dmitrygx]

they should have different names then

UCS_TERNARY_[YES|NO|TRY]
UCS_YNTA_[YES|NO|TRY|AUTO]

then it will be impossible to re-use code for ternary to handle yes/no/try
what about removing ternary type and have ynta?

[yosefe]

then it will be impossible to re-use code for ternary to handle yes/no/try
what about removing ternary type and have ynta?

What will we do in code which expects only yes/no/try options?

[dmitrygx]

then it will be impossible to re-use code for ternary to handle yes/no/try
what about removing ternary type and have ynta?

What will we do in code which expects only yes/no/try options?

I see
@yosefe wdyt about changing ucs_ternary_value_t -> ucs_ternary_auto_value_t? and we will have UCS_CONFIG_TYPE_TERNARY and UCS_CONFIG_TYPE_TERNARY_AUTO like we have for UCS_CONFIG_TYPE_ON_OFF/UCS_CONFIG_TYPE_ON_OFF_AUTO. sscanf() parsing function will be different for them to handle or not handle auto value

[dmitrygx]

then it will be impossible to re-use code for ternary to handle yes/no/try
what about removing ternary type and have ynta?

What will we do in code which expects only yes/no/try options?

I see
@yosefe wdyt about changing ucs_ternary_value_t -> ucs_ternary_auto_value_t? and we will have UCS_CONFIG_TYPE_TERNARY and UCS_CONFIG_TYPE_TERNARY_AUTO like we have for UCS_CONFIG_TYPE_ON_OFF/UCS_CONFIG_TYPE_ON_OFF_AUTO. sscanf() parsing function will be different for them to handle or not handle auto value

@yosefe implemented it to get your review

[dmitrygx]

bot:pipe:retest

[yosefe]

/azp run

[yosefe]

bot:pipe:retest

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[dmitrygx]

bot:pipe:retest

[dmitrygx]

@yosefe can we merge ignoring io demo failure?
it is unrelated to the PR