From: Jason Gunthorpe <jgg@nvidia.com>
To: Leon Romanovsky <leon@kernel.org>
Cc: Mark Zhang <markzhang@nvidia.com>,
Bart Van Assche <bvanassche@acm.org>,
linux-rdma@vger.kernel.org, Mark Bloch <mbloch@nvidia.com>
Subject: Re: [PATCH rdma-next 2/4] RDMA/cma: Multiple path records support with netlink channel
Date: Thu, 22 Sep 2022 10:58:12 -0300 [thread overview]
Message-ID: <Yyxp9E9pJtUids2o@nvidia.com> (raw)
In-Reply-To: <2fa2b6c93c4c16c8915bac3cfc4f27be1d60519d.1662631201.git.leonro@nvidia.com>
On Thu, Sep 08, 2022 at 01:09:01PM +0300, Leon Romanovsky wrote:
> +static void route_set_path_rec_inbound(struct cma_work *work,
> + struct sa_path_rec *path_rec)
> +{
> + struct rdma_route *route = &work->id->id.route;
> +
> + if (!route->path_rec_inbound) {
> + route->path_rec_inbound =
> + kzalloc(sizeof(*route->path_rec_inbound), GFP_KERNEL);
> + if (!route->path_rec_inbound)
> + return;
> + }
> +
> + *route->path_rec_inbound = *path_rec;
> +}
We are just ignoring these memory allocation failures??
> static void cma_query_handler(int status, struct sa_path_rec *path_rec,
> - void *context)
> + int num_prs, void *context)
This param should be "unsigned int num_prs"
> {
> struct cma_work *work = context;
> struct rdma_route *route;
> + int i;
>
> route = &work->id->id.route;
>
> - if (!status) {
> - route->num_pri_alt_paths = 1;
> - *route->path_rec = *path_rec;
> - } else {
> - work->old_state = RDMA_CM_ROUTE_QUERY;
> - work->new_state = RDMA_CM_ADDR_RESOLVED;
> - work->event.event = RDMA_CM_EVENT_ROUTE_ERROR;
> - work->event.status = status;
> - pr_debug_ratelimited("RDMA CM: ROUTE_ERROR: failed to query path. status %d\n",
> - status);
> + if (status)
> + goto fail;
> +
> + for (i = 0; i < num_prs; i++) {
> + if (!path_rec[i].flags || (path_rec[i].flags & IB_PATH_GMP))
> + *route->path_rec = path_rec[i];
> + else if (path_rec[i].flags & IB_PATH_INBOUND)
> + route_set_path_rec_inbound(work, &path_rec[i]);
> + else if (path_rec[i].flags & IB_PATH_OUTBOUND)
> + route_set_path_rec_outbound(work, &path_rec[i]);
> + }
> + if (!route->path_rec) {
Why is this needed? The for loop above will have already oops'd.
> +/**
> + * ib_sa_pr_callback_multiple() - Parse path records then do callback.
> + *
> + * In a multiple-PR case the PRs are saved in "query->resp_pr_data"
> + * (instead of"mad->data") and with "ib_path_rec_data" structure format,
> + * so that rec->flags can be set to indicate the type of PR.
> + * This is valid only in IB fabric.
> + */
> +static void ib_sa_pr_callback_multiple(struct ib_sa_path_query *query,
> + int status, int num_prs,
> + struct ib_path_rec_data *rec_data)
> +{
> + struct sa_path_rec *rec;
> + int i;
> +
> + rec = kvcalloc(num_prs, sizeof(*rec), GFP_KERNEL);
> + if (!rec) {
> + query->callback(-ENOMEM, NULL, 0, query->context);
> + return;
> + }
This all seems really wild, why are we allocating memory so many times
on this path? Have ib_nl_process_good_resolve_rsp unpack the mad
instead of storing the raw format
It would also be good to make resp_pr_data always valid so all these
special paths don't need to exist.
> diff --git a/include/rdma/rdma_cm.h b/include/rdma/rdma_cm.h
> index 81916039ee24..cdc7cafab572 100644
> --- a/include/rdma/rdma_cm.h
> +++ b/include/rdma/rdma_cm.h
> @@ -49,9 +49,15 @@ struct rdma_addr {
> struct rdma_dev_addr dev_addr;
> };
>
> +#define RDMA_PRIMARY_PATH_MAX_REC_NUM 3
This is a strange place for this define, it should be in sa_query.c?
Jason
next prev parent reply other threads:[~2022-09-22 13:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-08 10:08 [PATCH rdma-next 0/4] Support multiple path records Leon Romanovsky
2022-09-08 10:09 ` [PATCH rdma-next 1/4] RDMA/core: Rename rdma_route.num_paths field to num_pri_alt_paths Leon Romanovsky
2022-09-08 10:09 ` [PATCH rdma-next 2/4] RDMA/cma: Multiple path records support with netlink channel Leon Romanovsky
2022-09-22 13:58 ` Jason Gunthorpe [this message]
2022-09-23 1:40 ` Mark Zhang
2022-09-23 13:13 ` Jason Gunthorpe
2022-09-23 14:24 ` Mark Zhang
2022-09-23 14:50 ` Mark Zhang
2022-09-23 18:19 ` Jason Gunthorpe
2022-09-08 10:09 ` [PATCH rdma-next 3/4] RDMA/cm: Use SLID in the work completion as the DLID in responder side Leon Romanovsky
2022-09-08 10:09 ` [PATCH rdma-next 4/4] RDMA/cm: Use DLID from inbound/outbound PathRecords as the datapath DLID Leon Romanovsky
2022-09-22 9:36 ` [PATCH rdma-next 0/4] Support multiple path records Leon Romanovsky
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=Yyxp9E9pJtUids2o@nvidia.com \
--to=jgg@nvidia.com \
--cc=bvanassche@acm.org \
--cc=leon@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=markzhang@nvidia.com \
--cc=mbloch@nvidia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.