> -----Original Message-----
> From: linux-rdma-owner@xxxxxxxxxxxxxxx <linux-rdma-
> owner@xxxxxxxxxxxxxxx> On Behalf Of Leon Romanovsky
> Sent: Friday, March 30, 2018 5:36 AM
> To: Steve Wise <swise@xxxxxxxxxxxxxxxxxxxxx>
> Cc: jgg@xxxxxxxxxxxx; dledford@xxxxxxxxxx; linux-rdma@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH v2 rdma-next 3/5] RDMA/nldev: add provider-specific
> device/port tracking
>
> On Thu, Mar 29, 2018 at 09:09:51AM -0700, Steve Wise wrote:
> > Add fill_dev_info and fill_port_info functions to rdma_restrack_root.
> > This allows providers to have provider-specific fill functions for
device
> > and port restrack operations.
> >
> > Signed-off-by: Steve Wise <swise@xxxxxxxxxxxxxxxxxxxxx>
> > ---
> > drivers/infiniband/core/nldev.c | 35 +++++++++++++++++++++++++++++---
> ---
> > include/rdma/restrack.h | 15 +++++++++++++++
> > 2 files changed, 44 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/infiniband/core/nldev.c
> b/drivers/infiniband/core/nldev.c
> > index 99df8d4..902517f 100644
> > --- a/drivers/infiniband/core/nldev.c
> > +++ b/drivers/infiniband/core/nldev.c
> > @@ -115,6 +115,22 @@ static int provider_fill_res_entry(struct
> rdma_restrack_root *resroot,
> > resroot->fill_res_entry(msg, cb, res) : 0;
> > }
> >
> > +static int provider_fill_dev_info(struct sk_buff *msg,
> > + struct netlink_callback *cb,
> > + struct ib_device *device)
> > +{
> > + return device->res.fill_dev_info ?
> > + device->res.fill_dev_info(msg, cb, device) : 0;
> > +}
> > +
> > +static int provider_fill_port_info(struct sk_buff *msg,
> > + struct netlink_callback *cb,
> > + struct ib_device *device, u32 port)
> > +{
> > + return device->res.fill_port_info ?
> > + device->res.fill_port_info(msg, cb, device, port) : 0;
> > +}
> > +
> > static int fill_nldev_handle(struct sk_buff *msg, struct ib_device
*device)
> > {
> > if (nla_put_u32(msg, RDMA_NLDEV_ATTR_DEV_INDEX, device-
> >index))
> > @@ -125,7 +141,8 @@ static int fill_nldev_handle(struct sk_buff *msg,
> struct ib_device *device)
> > return 0;
> > }
> >
> > -static int fill_dev_info(struct sk_buff *msg, struct ib_device *device)
> > +static int fill_dev_info(struct sk_buff *msg, struct netlink_callback
*cb,
> > + struct ib_device *device)
> > {
> > char fw[IB_FW_VERSION_NAME_MAX];
> >
> > @@ -156,10 +173,14 @@ static int fill_dev_info(struct sk_buff *msg,
> struct ib_device *device)
> > return -EMSGSIZE;
> > if (nla_put_u8(msg, RDMA_NLDEV_ATTR_DEV_NODE_TYPE, device-
> >node_type))
> > return -EMSGSIZE;
> > +
> > + if (provider_fill_dev_info(msg, cb, device))
> > + return -EMSGSIZE;
> > +
> > return 0;
> > }
> >
> > -static int fill_port_info(struct sk_buff *msg,
> > +static int fill_port_info(struct sk_buff *msg, struct netlink_callback
*cb,
> > struct ib_device *device, u32 port)
> > {
> > struct ib_port_attr attr;
> > @@ -195,6 +216,8 @@ static int fill_port_info(struct sk_buff *msg,
> > return -EMSGSIZE;
> > if (nla_put_u8(msg, RDMA_NLDEV_ATTR_PORT_PHYS_STATE,
> attr.phys_state))
> > return -EMSGSIZE;
> > + if (provider_fill_port_info(msg, cb, device, port))
> > + return -EMSGSIZE;
> > return 0;
> > }
> >
> > @@ -554,7 +577,7 @@ static int nldev_get_doit(struct sk_buff *skb,
> struct nlmsghdr *nlh,
> > RDMA_NL_GET_TYPE(RDMA_NL_NLDEV,
> RDMA_NLDEV_CMD_GET),
> > 0, 0);
> >
> > - err = fill_dev_info(msg, device);
> > + err = fill_dev_info(msg, NULL, device);
>
> I look on this line and think that providing "struct netlink_callback *cb"
> to drivers is too broad approach. The right thing will be to pass
> "u64 caps_falgs" variable which will have bits on/off per
> uapi/linux/capability.h.
>
> However, you don't use this functionality for now, so it will make sense
> do not implement it completely and simply leave comment in the code how
> it should be implemented in the future.
>
> Thanks
Do you think the fill_res_entry API should also have this change? Is there
still time for me to respin this and make the merge window?
--
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
