From: Jason Gunthorpe <jgg@ziepe.ca>
To: liweihang <liweihang@huawei.com>
Cc: "dledford@redhat.com" <dledford@redhat.com>,
"leon@kernel.org" <leon@kernel.org>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
Linuxarm <linuxarm@huawei.com>
Subject: Re: [PATCH v2 for-next 04/10] RDMA/hns: Optimize hns_roce_alloc_vf_resource()
Date: Fri, 27 Mar 2020 09:36:42 -0300 [thread overview]
Message-ID: <20200327123642.GT20941@ziepe.ca> (raw)
In-Reply-To: <B82435381E3B2943AA4D2826ADEF0B3A022B650A@DGGEML502-MBS.china.huawei.com>
On Fri, Mar 27, 2020 at 07:09:02AM +0000, liweihang wrote:
> On 2020/3/27 3:51, Jason Gunthorpe wrote:
> > On Fri, Mar 20, 2020 at 11:23:36AM +0800, Weihang Li wrote:
> >
> >> @@ -2028,6 +2002,13 @@ static int hns_roce_v2_profile(struct hns_roce_dev *hr_dev)
> >> if (ret)
> >> set_default_caps(hr_dev);
> >>
> >> + ret = hns_roce_alloc_vf_resource(hr_dev);
> >> + if (ret) {
> >> + dev_err(hr_dev->dev, "Allocate vf resource fail, ret = %d.\n",
> >> + ret);
> >> + return ret;
> >> + }
> >
> > It is unfortunate these have to remain as dev_err()
> >
> > I've thought about setting the name during ib_alloc_dev, which would
> > avoid this, what do you think?
> >
> > Jason
> >
>
> Hi Jason,
>
> Thanks for your comments. I agree with you and make a simple test by just
> moving assign_name() into _ib_alloc_device(), and ibdev_*() works fine
> anywhere in hns. But I'm not sure if there are any side effects.
Hmm. It actually looks like it should work now, older versions may
have had problems, but this looks OK.
Jason
next prev parent reply other threads:[~2020-03-27 12:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-20 3:23 [PATCH v2 for-next 00/10] RDMA/hns: Various cleanups Weihang Li
2020-03-20 3:23 ` [PATCH v2 for-next 01/10] RDMA/hns: Unify format of prints Weihang Li
2020-03-20 3:23 ` [PATCH v2 for-next 02/10] RDMA/hns: Fix a wrong judgment of return value Weihang Li
2020-03-20 3:23 ` [PATCH v2 for-next 03/10] RDMA/hns: Simplify attribute judgment code Weihang Li
2020-03-20 3:23 ` [PATCH v2 for-next 04/10] RDMA/hns: Optimize hns_roce_alloc_vf_resource() Weihang Li
2020-03-26 19:51 ` Jason Gunthorpe
2020-03-27 7:09 ` liweihang
2020-03-27 12:36 ` Jason Gunthorpe [this message]
2020-03-28 1:55 ` liweihang
2020-03-20 3:23 ` [PATCH v2 for-next 05/10] RDMA/hns: Adjust the qp status value sequence of the hardware Weihang Li
2020-03-20 3:23 ` [PATCH v2 for-next 06/10] RDMA/hns: Remove definition of cq doorbell structure Weihang Li
2020-03-20 3:23 ` [PATCH v2 for-next 07/10] RDMA/hns: Remove meaningless prints Weihang Li
2020-03-20 3:23 ` [PATCH v2 for-next 08/10] RDMA/hns: Remove redundant qpc setup operations Weihang Li
2020-03-20 3:23 ` [PATCH v2 for-next 09/10] RDMA/hns: Remove redundant assignment of wc->smac when polling cq Weihang Li
2020-03-20 3:23 ` [PATCH v2 for-next 10/10] RDMA/hns: Remove redundant judgment of qp_type Weihang Li
2020-03-26 19:55 ` [PATCH v2 for-next 00/10] RDMA/hns: Various cleanups Jason Gunthorpe
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=20200327123642.GT20941@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=dledford@redhat.com \
--cc=leon@kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).