Skip to contentSkip to conversation

Question about IB_QP_CUR_STATE

DISCUSSION liweihang 3 participants 9 messages Jul 8, 2020 – Jul 12, 2020 InfiniBand

lore
Share & tools
lore

liweihang

author
#0 lore raw

Hi all,

I'm a little confused about the role of IB_QP_CUR_STATE in the enumeration ib_qp_attr_mask.

In manual page of ibv_modify_qp(), comments of cur_qp_state is "Assume this is the current QP state". Why we need to get current qp state from users instead of drivers?

For example, why the users are allowed to modify qp from RTR to RTS again even if the qp's state in driver and hardware has already been RTS.

I would be appretiate it if someone can help with this.

Weihang

#1 lore raw
Quoted 5 lines · liweihang

Hi all,

I'm a little confused about the role of IB_QP_CUR_STATE in the enumeration ib_qp_attr_mask.

Quoted 8 lines

In manual page of ibv_modify_qp(), comments of cur_qp_state is "Assume this is the current QP state". Why we need to get current qp state from users instead of drivers?

For example, why the users are allowed to modify qp from RTR to RTS again even if the qp's state in driver and hardware has already been RTS.

I would be appretiate it if someone can help with this.

See, IBTA section "11.2.5.2 MODIFY QUEUE PAIR", table 96. "Current QP state" is valid optional attribute in modify_qp() while transition to RTS.

I guess that the reason is to sync QP states seen by SW with HW.

Thanks

Quoted 2 lines

Weihang

#2 lore raw
In reply to liweihang
Quoted 9 lines · liweihang

Hi all,

I'm a little confused about the role of IB_QP_CUR_STATE in the enumeration ib_qp_attr_mask.

In manual page of ibv_modify_qp(), comments of cur_qp_state is "Assume this is the current QP state". Why we need to get current qp state from users instead of drivers?

Quoted 7 lines

For example, why the users are allowed to modify qp from RTR to RTS again even if the qp's state in driver and hardware has already been RTS.

I would be appretiate it if someone can help with this.

Weihang

Talking about IB_QP_CUR_STATE, I see many drivers filling it in their query QP callback although it should only be used in modify operations.. Is there a reason not to remove it?

#3 lore raw
Quoted 13 lines · Gal Pressman
Quoted 12 lines · liweihang

Hi all,

I'm a little confused about the role of IB_QP_CUR_STATE in the enumeration ib_qp_attr_mask.

In manual page of ibv_modify_qp(), comments of cur_qp_state is "Assume this is the current QP state". Why we need to get current qp state from users instead of drivers?

For example, why the users are allowed to modify qp from RTR to RTS again even if the qp's state in driver and hardware has already been RTS.

Quoted 8 lines
Quoted 4 lines

I would be appretiate it if someone can help with this.

Weihang

Talking about IB_QP_CUR_STATE, I see many drivers filling it in their query QP callback although it should only be used in modify operations.. Is there a reason not to remove it?

IBTA section "11.2.5.3 QUERY QUEUE PAIR" has line about IB_QP_CUR_STATE. It is one of output modifiers.

Thanks

#4 lore raw
Quoted 19 lines · Leon Romanovsky
Quoted 18 lines · Gal Pressman
Quoted 16 lines · liweihang

Hi all,

I'm a little confused about the role of IB_QP_CUR_STATE in the enumeration ib_qp_attr_mask.

In manual page of ibv_modify_qp(), comments of cur_qp_state is "Assume this is the current QP state". Why we need to get current qp state from users instead of drivers?

For example, why the users are allowed to modify qp from RTR to RTS again even if the qp's state in driver and hardware has already been RTS.

I would be appretiate it if someone can help with this.

Weihang

Quoted 9 lines
Quoted 3 lines

Talking about IB_QP_CUR_STATE, I see many drivers filling it in their query QP callback although it should only be used in modify operations.. Is there a reason not to remove it?

IBTA section "11.2.5.3 QUERY QUEUE PAIR" has line about IB_QP_CUR_STATE. It is one of output modifiers.

Thanks

It says the current QP state should be returned, that's what qp_state field is used for. According to the man pages:

libibverbs/man/ibv_query_qp.3:

               enum ibv_qp_state       qp_state;            /* Current QP state */
               enum ibv_qp_state       cur_qp_state;        /* Current QP state - irrelevant for ibv_query_qp */
author
#5 lore raw
Quoted 30 lines · Gal Pressman
Quoted 19 lines · Leon Romanovsky
Quoted 18 lines · Gal Pressman
Quoted 16 lines · liweihang

Hi all,

I'm a little confused about the role of IB_QP_CUR_STATE in the enumeration ib_qp_attr_mask.

In manual page of ibv_modify_qp(), comments of cur_qp_state is "Assume this is the current QP state". Why we need to get current qp state from users instead of drivers?

For example, why the users are allowed to modify qp from RTR to RTS again even if the qp's state in driver and hardware has already been RTS.

I would be appretiate it if someone can help with this.

Weihang

Quoted 9 lines
Quoted 3 lines

Talking about IB_QP_CUR_STATE, I see many drivers filling it in their query QP callback although it should only be used in modify operations.. Is there a reason not to remove it?

IBTA section "11.2.5.3 QUERY QUEUE PAIR" has line about IB_QP_CUR_STATE. It is one of output modifiers.

Thanks

Quoted 7 lines

It says the current QP state should be returned, that's what qp_state field is used for. According to the man pages:

libibverbs/man/ibv_query_qp.3:

               enum ibv_qp_state       qp_state;            /* Current QP state */
               enum ibv_qp_state       cur_qp_state;        /* Current QP state - irrelevant for ibv_query_qp */

Hi Gal and Leon,

Thanks for your reply, as Gal said, I can't find the reason why the IBTA use cur_qp_state either. I'll take a closer look at the protocol.

Weihang

#6 lore raw
In reply to Gal Pressman
Quoted 30 lines · Gal Pressman
Quoted 19 lines · Leon Romanovsky
Quoted 18 lines · Gal Pressman
Quoted 16 lines · liweihang

Hi all,

I'm a little confused about the role of IB_QP_CUR_STATE in the enumeration ib_qp_attr_mask.

In manual page of ibv_modify_qp(), comments of cur_qp_state is "Assume this is the current QP state". Why we need to get current qp state from users instead of drivers?

For example, why the users are allowed to modify qp from RTR to RTS again even if the qp's state in driver and hardware has already been RTS.

I would be appretiate it if someone can help with this.

Weihang

Quoted 9 lines
Quoted 3 lines

Talking about IB_QP_CUR_STATE, I see many drivers filling it in their query QP callback although it should only be used in modify operations.. Is there a reason not to remove it?

IBTA section "11.2.5.3 QUERY QUEUE PAIR" has line about IB_QP_CUR_STATE. It is one of output modifiers.

Thanks

Quoted 6 lines

It says the current QP state should be returned, that's what qp_state field is used for. According to the man pages:

libibverbs/man/ibv_query_qp.3:

               enum ibv_qp_state       qp_state;            /* Current QP state */
               enum ibv_qp_state       cur_qp_state;        /* Current QP state - irrelevant for ibv_query_qp */

I don't think that users read it, because ibv_cmd_query_qp() filled qp_state to be equal to cur_qp_state from day one.

Thanks

#7 lore raw
Quoted 34 lines · Leon Romanovsky
Quoted 33 lines · Gal Pressman
Quoted 19 lines · Leon Romanovsky
Quoted 18 lines · Gal Pressman
Quoted 16 lines · liweihang

Hi all,

I'm a little confused about the role of IB_QP_CUR_STATE in the enumeration ib_qp_attr_mask.

In manual page of ibv_modify_qp(), comments of cur_qp_state is "Assume this is the current QP state". Why we need to get current qp state from users instead of drivers?

For example, why the users are allowed to modify qp from RTR to RTS again even if the qp's state in driver and hardware has already been RTS.

I would be appretiate it if someone can help with this.

Weihang

Quoted 9 lines
Quoted 3 lines

Talking about IB_QP_CUR_STATE, I see many drivers filling it in their query QP callback although it should only be used in modify operations.. Is there a reason not to remove it?

IBTA section "11.2.5.3 QUERY QUEUE PAIR" has line about IB_QP_CUR_STATE. It is one of output modifiers.

Thanks

It says the current QP state should be returned, that's what qp_state field is used for. According to the man pages:

Quoted 6 lines
Quoted 3 lines

libibverbs/man/ibv_query_qp.3:

               enum ibv_qp_state       qp_state;            /* Current QP state */
               enum ibv_qp_state       cur_qp_state;        /* Current QP state - irrelevant for ibv_query_qp */

I don't think that users read it, because ibv_cmd_query_qp() filled qp_state to be equal to cur_qp_state from day one.

Where do you see that?

I see:
ibv_cmd_query_qp():

	attr->qp_state                      = resp.qp_state;
	attr->cur_qp_state                  = resp.cur_qp_state;
#8 lore raw
Quoted 42 lines · Gal Pressman
Quoted 34 lines · Leon Romanovsky
Quoted 33 lines · Gal Pressman
Quoted 19 lines · Leon Romanovsky
Quoted 18 lines · Gal Pressman
Quoted 16 lines · liweihang

Hi all,

I'm a little confused about the role of IB_QP_CUR_STATE in the enumeration ib_qp_attr_mask.

In manual page of ibv_modify_qp(), comments of cur_qp_state is "Assume this is the current QP state". Why we need to get current qp state from users instead of drivers?

For example, why the users are allowed to modify qp from RTR to RTS again even if the qp's state in driver and hardware has already been RTS.

I would be appretiate it if someone can help with this.

Weihang

Quoted 9 lines
Quoted 3 lines

Talking about IB_QP_CUR_STATE, I see many drivers filling it in their query QP callback although it should only be used in modify operations.. Is there a reason not to remove it?

IBTA section "11.2.5.3 QUERY QUEUE PAIR" has line about IB_QP_CUR_STATE. It is one of output modifiers.

Thanks

It says the current QP state should be returned, that's what qp_state field is used for. According to the man pages:

Quoted 6 lines
Quoted 3 lines

libibverbs/man/ibv_query_qp.3:

               enum ibv_qp_state       qp_state;            /* Current QP state */
               enum ibv_qp_state       cur_qp_state;        /* Current QP state - irrelevant for ibv_query_qp */

I don't think that users read it, because ibv_cmd_query_qp() filled qp_state to be equal to cur_qp_state from day one.

Quoted 6 lines

Where do you see that?

I see:
ibv_cmd_query_qp():

	attr->qp_state                      = resp.qp_state;
	attr->cur_qp_state                  = resp.cur_qp_state;

It comes from the the kernel as is and in the kernel:
mlx5_ib_query_qp():

  4699         qp_attr->qp_state            = qp->state;
  4700         qp_attr->cur_qp_state        = qp_attr->qp_state;

mlx4_ib_query_qp():

  4049         qp->state                    = to_ib_qp_state(mlx4_state);
  4050         qp_attr->qp_state            = qp->state;

Thanks