From: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Jason Gunthorpe <jgg-uk2M96/98Pc@public.gmane.org>
Cc: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
RDMA mailing list
<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Mark Bloch <markb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
Steve Wise
<swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
Subject: Re: [PATCH rdma-next v7 7/8] RDMA/nldev: Provide global resource utilization
Date: Mon, 29 Jan 2018 07:09:22 +0200 [thread overview]
Message-ID: <20180129050922.GA1393@mtr-leonro.local> (raw)
In-Reply-To: <20180128204513.GH23869-uk2M96/98Pc@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3331 bytes --]
On Sun, Jan 28, 2018 at 01:45:13PM -0700, Jason Gunthorpe wrote:
> On Sun, Jan 28, 2018 at 11:17:24AM +0200, Leon Romanovsky wrote:
>
> > @@ -52,6 +54,11 @@ static const struct nla_policy nldev_policy[RDMA_NLDEV_ATTR_MAX] = {
> > [RDMA_NLDEV_ATTR_PORT_STATE] = { .type = NLA_U8 },
> > [RDMA_NLDEV_ATTR_PORT_PHYS_STATE] = { .type = NLA_U8 },
> > [RDMA_NLDEV_ATTR_DEV_NODE_TYPE] = { .type = NLA_U8 },
> > + [RDMA_NLDEV_ATTR_RES_SUMMARY] = { .type = NLA_NESTED },
> > + [RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY] = { .type = NLA_NESTED },
> > + [RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY_NAME] = { .type = NLA_NUL_STRING,
> > + .len = 16 },
> > + [RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY_CURR] = { .type = NLA_U64 },
>
> nla_policy is only used during kernel parsing, it shouldn't have
> anything the kernel will not accept as input, right? ie it should omit
> things that are output only?
The common practice for netlink code is to add nla_policy for every exposed
attribute. It achieves number of goals. First, future tools which will
send those attributes as inputs will be matched to ensure that UAPI
contract is still valid, despite the fact that it is not used in the
code. Second, once kernel developers will add needed implementation to
use those attributes as inputs, they are not supposed to touch this
policy, and it will be in sync with the output from the beginning - easy
review, easy maintenance.
>
> > static const struct rdma_nl_cbs nldev_cb_table[RDMA_NLDEV_NUM_OPS] = {
> > [RDMA_NLDEV_CMD_GET] = {
> > .doit = nldev_get_doit,
> > @@ -338,6 +485,10 @@ static const struct rdma_nl_cbs nldev_cb_table[RDMA_NLDEV_NUM_OPS] = {
> > .doit = nldev_port_get_doit,
> > .dump = nldev_port_get_dumpit,
> > },
> > + [RDMA_NLDEV_CMD_RES_GET] = {
> > + .doit = nldev_res_get_doit,
> > + .dump = nldev_res_get_dumpit,
> > + },
> > };
> >
> > void __init nldev_init(void)
> > diff --git a/include/uapi/rdma/rdma_netlink.h b/include/uapi/rdma/rdma_netlink.h
> > index cc002e316d09..e0f5cdc81541 100644
> > +++ b/include/uapi/rdma/rdma_netlink.h
> > @@ -236,6 +236,11 @@ enum rdma_nldev_command {
> > RDMA_NLDEV_CMD_PORT_NEW,
> > RDMA_NLDEV_CMD_PORT_DEL,
> >
> > + RDMA_NLDEV_CMD_RES_GET, /* can dump */
> > + RDMA_NLDEV_CMD_RES_SET,
> > + RDMA_NLDEV_CMD_RES_NEW,
> > + RDMA_NLDEV_CMD_RES_DEL,
>
> Confused why all thse have get/set/new/del tuples and then don't
> implement all of them. Is there some reason for this?
>
> AFAIK netlink doesn't have any rules for numbering get/set/new/del, so
> why can't we just add when we need?
Maybe, it is cargo cult, but I followed devlink and devlink does such
to follow ip tool paradigm where every object can have those properties
(GET/SET/NEW/DEL).
The current declaration places all commands in one place.
Otherwise, this structure will be mixed with different commands.
>
> > @@ -303,6 +308,11 @@ enum rdma_nldev_attr {
> >
> > RDMA_NLDEV_ATTR_DEV_NODE_TYPE, /* u8 */
> >
> > + RDMA_NLDEV_ATTR_RES_SUMMARY, /* nested table */
> > + RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY, /* nested table */
> > + RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY_NAME, /* string */
> > + RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY_CURR, /* u64 */
>
> Had to look it up to figure out what CURR was..
>
> ENTRY_NUM_OBJECTS ?
I still didn't abandon my idea to provide ENTRY_MAX for the objects too.
>
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-01-29 5:09 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-28 9:17 [PATCH rdma-next v7 0/8] RDMA resource tracking Leon Romanovsky
[not found] ` <20180128091725.13103-1-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2018-01-28 9:17 ` [PATCH rdma-next v7 1/8] RDMA/core: Print caller name instead of function name Leon Romanovsky
2018-01-28 9:17 ` [PATCH rdma-next v7 2/8] RDMA/core: Save kernel caller name in PD and CQ objects Leon Romanovsky
2018-01-28 9:17 ` [PATCH rdma-next v7 3/8] RDMA/restrack: Add general infrastructure to track RDMA resources Leon Romanovsky
[not found] ` <20180128091725.13103-4-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2018-01-28 21:03 ` Jason Gunthorpe
[not found] ` <20180128210350.GJ23869-uk2M96/98Pc@public.gmane.org>
2018-01-29 5:37 ` Leon Romanovsky
2018-01-28 9:17 ` [PATCH rdma-next v7 4/8] RDMA/core: Add resource tracking for create and destroy QPs Leon Romanovsky
2018-01-28 9:17 ` [PATCH rdma-next v7 5/8] RDMA/core: Add resource tracking for create and destroy CQs Leon Romanovsky
2018-01-28 9:17 ` [PATCH rdma-next v7 6/8] RDMA/core: Add resource tracking for create and destroy PDs Leon Romanovsky
[not found] ` <20180128091725.13103-7-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2018-01-28 20:48 ` Jason Gunthorpe
[not found] ` <20180128204858.GI23869-uk2M96/98Pc@public.gmane.org>
2018-01-29 5:14 ` Leon Romanovsky
2018-01-28 9:17 ` [PATCH rdma-next v7 7/8] RDMA/nldev: Provide global resource utilization Leon Romanovsky
[not found] ` <20180128091725.13103-8-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2018-01-28 20:45 ` Jason Gunthorpe
[not found] ` <20180128204513.GH23869-uk2M96/98Pc@public.gmane.org>
2018-01-29 5:09 ` Leon Romanovsky [this message]
[not found] ` <20180129050922.GA1393-U/DQcQFIOTAAJjI8aNfphQ@public.gmane.org>
2018-01-29 17:59 ` Jason Gunthorpe
2018-01-28 9:17 ` [PATCH rdma-next v7 8/8] RDMA/nldev: Provide detailed QP information Leon Romanovsky
2018-01-28 21:05 ` [PATCH rdma-next v7 0/8] RDMA resource tracking Jason Gunthorpe
[not found] ` <20180128210520.GK23869-uk2M96/98Pc@public.gmane.org>
2018-01-29 5:39 ` Leon Romanovsky
2018-01-29 20:11 ` Doug Ledford
[not found] ` <1517256713.27592.241.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-01-30 3:34 ` Jason Gunthorpe
[not found] ` <20180130033436.GA17053-uk2M96/98Pc@public.gmane.org>
2018-01-30 9:16 ` Leon Romanovsky
[not found] ` <20180130091654.GD2055-U/DQcQFIOTAAJjI8aNfphQ@public.gmane.org>
2018-01-30 15:21 ` Steve Wise
2018-01-30 15:56 ` Jason Gunthorpe
[not found] ` <20180130155643.GC17053-uk2M96/98Pc@public.gmane.org>
2018-01-30 16:16 ` Steve Wise
2018-01-30 16:33 ` Jason Gunthorpe
[not found] ` <20180130163330.GE17053-uk2M96/98Pc@public.gmane.org>
2018-01-30 19:07 ` Bart Van Assche
[not found] ` <1517339252.2589.34.camel-Sjgp3cTcYWE@public.gmane.org>
2018-01-30 19:46 ` Jason Gunthorpe
[not found] ` <20180130194639.GJ17053-uk2M96/98Pc@public.gmane.org>
2018-01-30 20:42 ` Bart Van Assche
[not found] ` <1517344962.2589.39.camel-Sjgp3cTcYWE@public.gmane.org>
2018-01-30 20:48 ` Jason Gunthorpe
[not found] ` <20180130204840.GK17053-uk2M96/98Pc@public.gmane.org>
2018-01-30 21:22 ` Bart Van Assche
[not found] ` <1517347322.2589.58.camel-Sjgp3cTcYWE@public.gmane.org>
2018-01-30 21:33 ` Laurence Oberman
[not found] ` <1517347999.15224.2.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-01-30 21:40 ` Bart Van Assche
[not found] ` <1517348412.2589.60.camel-Sjgp3cTcYWE@public.gmane.org>
2018-01-30 21:42 ` Jason Gunthorpe
[not found] ` <20180130214227.GM17053-uk2M96/98Pc@public.gmane.org>
2018-01-30 21:47 ` Bart Van Assche
[not found] ` <1517348867.2589.63.camel-Sjgp3cTcYWE@public.gmane.org>
2018-01-30 22:02 ` Jason Gunthorpe
[not found] ` <20180130220233.GN17053-uk2M96/98Pc@public.gmane.org>
2018-01-30 22:10 ` Bart Van Assche
2018-01-30 21:40 ` 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=20180129050922.GA1393@mtr-leonro.local \
--to=leon-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
--cc=dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=jgg-uk2M96/98Pc@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=markb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org \
--cc=swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org \
/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