From: Leon Romanovsky <leon@kernel.org>
To: Tao Cui <cuitao@kylinos.cn>
Cc: jgg@ziepe.ca, linux-rdma@vger.kernel.org
Subject: Re: [PATCH 1/2] RDMA/nldev: add resource summary max values for usage rate display
Date: Thu, 14 May 2026 14:44:17 +0300 [thread overview]
Message-ID: <20260514114417.GP15586@unreal> (raw)
In-Reply-To: <4ab73129-b690-497c-83b1-d2065f52e7bd@kylinos.cn>
On Tue, May 12, 2026 at 03:38:59PM +0800, Tao Cui wrote:
>
> Hi,Leon
>
> Thanks for the review. You're right that a percentage alone is not
> very helpful to users.
>
> 在 2026/5/11 18:12, Leon Romanovsky 写道:
> > On Thu, Apr 23, 2026 at 02:13:51PM +0800, Tao Cui wrote:
> >> Add RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY_MAX netlink attribute to expose
> >> device resource limits (max_qp, max_cq, max_mr, max_pd, max_srq) in
> >> the resource summary alongside the existing current count. This allows
> >> userspace tools like iproute2's rdma to display resource usage rates.
> >
> > While I'm fine with the overall idea, I think we should spend more time
> > determining the proper display format for this information. Once we agree
> > on how it should be presented, that output should be included in the commit
> > message.
> >
> > Presenting utilization as a percentage seems too imprecise, and users would
> > likely prefer to see the maximum value instead.
> >
> > Thanks
>
> I originally chose the percentage format for its intuitiveness.
> The expected output was described in the corresponding iproute2
> patch [1], but I should have included it in this kernel commit
> message as well.
>
> [1] https://lore.kernel.org/all/20260423064711.360024-1-cuitao@kylinos.cn/
>
> Here are the display formats I considered:
> 1) qp 123 (0.0%) -- percentage only, loses the actual max
> 2) qp 123 (max 131072) -- clear but verbose
> 3) qp 123/131072 -- curr/max, concise and common in Linux tools
> 4) qp 123/131072 (0.0%) -- all info, but too crowded for one line
>
> After comparing them, I think format 3 is the best fit. It is concise,
> follows conventions used by other Linux tools (e.g. df, free), and
> users can easily estimate the percentage from the curr/max values.
>
> Before: 0: mlx5_0: qp 123 cq 45 mr 200 pd 10
> After: 0: mlx5_0: qp 123/131072 cq 45/65536 mr 200/1000000 pd 10/32768
>
> In JSON output, both "curr" and "max" fields will be provided so that
> scripts can compute percentages if needed.
>
> The kernel side change (exposing the max value) remains the same. I'll
> update the commit messages to include the expected output format and
> resubmit.
>
> Does this look acceptable?
Yes, I agree that option number 3 appears to be the best choice.
Thanks
prev parent reply other threads:[~2026-05-14 11:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-23 6:13 [PATCH 1/2] RDMA/nldev: add resource summary max values for usage rate display Tao Cui
2026-04-23 6:13 ` [PATCH 2/2] selftests/rdma: add resource usage rate display test Tao Cui
2026-04-26 12:42 ` [PATCH 1/2] RDMA/nldev: add resource summary max values for usage rate display Leon Romanovsky
2026-04-26 12:47 ` Leon Romanovsky
2026-04-28 8:20 ` Tao Cui
2026-05-11 10:12 ` Leon Romanovsky
2026-05-12 7:38 ` Tao Cui
2026-05-14 11:44 ` Leon Romanovsky [this message]
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=20260514114417.GP15586@unreal \
--to=leon@kernel.org \
--cc=cuitao@kylinos.cn \
--cc=jgg@ziepe.ca \
--cc=linux-rdma@vger.kernel.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 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.