> -----Original Message----- > From: Steve Wise [mailto:swise@xxxxxxxxxxxxxxxxxxxxx] > Sent: Tuesday, February 13, 2018 2:59 PM > To: Parav Pandit <parav@xxxxxxxxxxxx>; Jason Gunthorpe > <jgg@xxxxxxxxxxxx>; dledford@xxxxxxxxxx > Cc: linux-rdma@xxxxxxxxxxxxxxx; leon@xxxxxxxxxx > Subject: RE: [PATCH RESEND v1 rdma-next 2/6] RDMA/nldev: provide detailed > CM_ID information > > ... > > > > + /* > > > + * 1. Kernel QPs should be visible in init namsapce > only > > > + * 2. Preent only QPs visible in the current > namespace > > Present only > > > Yup. Thanks. > > ... > > > > diff --git a/include/rdma/rdma_cm.h b/include/rdma/rdma_cm.h index > > > 6538a5c..3e90501 100644 > > > --- a/include/rdma/rdma_cm.h > > > +++ b/include/rdma/rdma_cm.h > > > @@ -155,8 +155,19 @@ struct rdma_cm_id { > > > enum rdma_port_space ps; > > > enum ib_qp_type qp_type; > > > u8 port_num; > > > + const char *caller; > > > + > > > + /* > > > + * Internal to RDMA/core, don't use in the drivers > > > + */ > > > + struct rdma_restrack_entry res; > > I didn't review the whole code; can this be kept in rdma_cm_priv_id > instead? > > Yes. I guess that probably makes sense. The other objects (ib_qp, ib_cq, > etc) don't have a public/private separation though. > True. rdma_cm_priv_id has lot more fields private than rdma_cm_id which I think deserves avoid exposing them to ULPs. Creating anything such private for cq, qp would be obviously overkill too at this point anyway. > Steve. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
