All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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.