Linux RDMA and InfiniBand development
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Gal Pressman <galpress@amazon.com>
Cc: liweihang <liweihang@huawei.com>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	Linuxarm <linuxarm@huawei.com>
Subject: Re: Question about IB_QP_CUR_STATE
Date: Sun, 12 Jul 2020 14:01:53 +0300	[thread overview]
Message-ID: <20200712110153.GB7287@unreal> (raw)
In-Reply-To: <ca040bc1-e5dc-e514-ace4-8145b7946664@amazon.com>

On Sun, Jul 12, 2020 at 01:53:13PM +0300, Gal Pressman wrote:
> On 12/07/2020 13:44, Leon Romanovsky wrote:
> > On Thu, Jul 09, 2020 at 09:13:45AM +0300, Gal Pressman wrote:
> >> On 08/07/2020 18:44, Leon Romanovsky wrote:
> >>> On Wed, Jul 08, 2020 at 03:42:34PM +0300, Gal Pressman wrote:
> >>>> On 08/07/2020 12:41, liweihang wrote:
> >>>>> 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
> >>>>>
> >>>>
> >>>> 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 */
> >
> > 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;

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

      reply	other threads:[~2020-07-12 11:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-08  9:41 Question about IB_QP_CUR_STATE liweihang
2020-07-08 12:20 ` Leon Romanovsky
2020-07-08 12:42 ` Gal Pressman
2020-07-08 15:44   ` Leon Romanovsky
2020-07-09  6:13     ` Gal Pressman
2020-07-10 10:11       ` liweihang
2020-07-12 10:44       ` Leon Romanovsky
2020-07-12 10:53         ` Gal Pressman
2020-07-12 11:01           ` Leon Romanovsky [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200712110153.GB7287@unreal \
    --to=leon@kernel.org \
    --cc=galpress@amazon.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=liweihang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox