All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Selvin Xavier <selvin.xavier@broadcom.com>
Cc: Kalesh Anakkur Purayil <kalesh-anakkur.purayil@broadcom.com>,
	jgg@ziepe.ca, linux-rdma@vger.kernel.org,
	andrew.gospodarek@broadcom.com
Subject: Re: [PATCH rdma-rext 0/4] RDMA/bnxt_re: Add QP rate limit support
Date: Wed, 28 Jan 2026 14:17:33 +0200	[thread overview]
Message-ID: <20260128121733.GA40916@unreal> (raw)
In-Reply-To: <CA+sbYW3dLsVqXcaG9xYdh-YRpdf6-ZjrMKRCBnapMY+gFzoA2w@mail.gmail.com>

On Wed, Jan 28, 2026 at 12:33:57PM +0530, Selvin Xavier wrote:
> On Tue, Jan 27, 2026 at 1:49 AM Leon Romanovsky <leon@kernel.org> wrote:
> >
> > On Sun, Jan 25, 2026 at 09:47:05AM +0530, Kalesh Anakkur Purayil wrote:
> > > Hi Leon, Jason,
> > >
> > > A gentle reminder. Could you please review the patch series?
> >
> > Sorry for the delayed response. The idea and implementation look fine to me.
> Thanks you for your response.
> > What is missing is a clear and well-documented definition of the semantics
> > of QP rate limiting for RC QPs.
> 
> man page of ibv_modify_qp doesn't have much information about rate limit
> 
>  struct ibv_qp_attr {
> ...
>           uint32_t                rate_limit;             /* Rate
> limit in kbps for packet pacing */
>        };
> 
> 
> attr_mask:IBV_QP_RATE_LIMIT  Set rate_limit
> 
> This man page contains only the required field for each transition and
> doesn't mention about the optional flags. Do you want us to add a
> section for the QP rate limit in the notes?

I would expect the changes to be in https://github.com/linux-rdma/rdma-core/blob/master/libibverbs/man/ibv_modify_qp_rate_limit.3
and your driver implements .modify_qp_rate_limit() callback in rdma-core.

> 
> >
> > How should RDMA_READ or small RDMA_REQ packets be treated? Are response
> > packets included in the rate limit as well? It must be documented in
> > man pages.
> 
> All transmitted packets (including rdma_read request and other request
> packets) will be part of rate limiting setting for the QP. In our
> implementation, the ack packets are not part of the rate limiting of
> the normal transmit path. READ data response will be rate limited at
> the peer side, if the rate limit is configured on the peer side.
> 
> We have another question. Existing implementation of IB_QP_RATE_LIMIT
> is applicable only for raw ethernet QP. With this change, we will
> start supporting for RC QPs also. So mlx driver can also get this
> request for RC QPs, but it will silently ignored as the QP type is not
> Raw ethernet QP. Should we fail the request instead?

We should return something to users, since it would be surprising if a
policy-related feature simply failed without notice.

The tricky part is deciding how to expose this so users can anticipate it
up front, especially since we're dealing with a generic verb.

Thanks

> 
> Thanks,
> Selvin Xavier
> >
> > Thanks
> >
> > >
> > > On Fri, Jan 16, 2026 at 2:43 PM Kalesh AP
> > > <kalesh-anakkur.purayil@broadcom.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > This patchset supports QP rate limit in the bnxt_re driver.
> > > >
> > > > Broadcom P7 devices supports setting the rate limit while changing
> > > > RC QP state from INIT to RTR, RTR to RTS and RTS to RTS. Or, once
> > > > the QP is transitioned to RTR or RTS state.
> > > >
> > > > First patch adds stack support for rate limit for RC QPs.
> > > >
> > > > Second patch adds support for QP rate limiting in the bnxt_re driver.
> > > >
> > > > Third patch adds support to report packet pacing capabilities in the
> > > > query_device.
> > > >
> > > > Forth patch adds support to report QP rate limit in debugfs QP info.
> > > >
> > > > The pull request for rdma-core changes are at:
> > > >
> > > > https://github.com/linux-rdma/rdma-core/pull/1692
> > > >
> > > > Regards,
> > > > Kalesh
> > > >
> > > > Kalesh AP (4):
> > > >   IB/core: Extend rate limit support for RC QPs
> > > >   RDMA/bnxt_re: Add support for QP rate limiting
> > > >   RDMA/bnxt_re: Report packet pacing capabilities when querying device
> > > >   RDMA/bnxt_re: Report QP rate limit in debugfs
> > > >
> > > >  drivers/infiniband/core/verbs.c           |  9 ++++--
> > > >  drivers/infiniband/hw/bnxt_re/debugfs.c   | 14 ++++++--
> > > >  drivers/infiniband/hw/bnxt_re/ib_verbs.c  | 39 +++++++++++++++++++++--
> > > >  drivers/infiniband/hw/bnxt_re/qplib_fp.c  | 12 ++++++-
> > > >  drivers/infiniband/hw/bnxt_re/qplib_fp.h  |  3 ++
> > > >  drivers/infiniband/hw/bnxt_re/qplib_res.h |  6 ++++
> > > >  drivers/infiniband/hw/bnxt_re/qplib_sp.c  |  5 +++
> > > >  drivers/infiniband/hw/bnxt_re/qplib_sp.h  |  2 ++
> > > >  drivers/infiniband/hw/bnxt_re/roce_hsi.h  | 13 +++++---
> > > >  include/uapi/rdma/bnxt_re-abi.h           | 16 ++++++++++
> > > >  10 files changed, 107 insertions(+), 12 deletions(-)
> > > >
> > > > --
> > > > 2.43.5
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Kalesh AP
> >
> >
> >



  reply	other threads:[~2026-01-28 12:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-16  9:18 [PATCH rdma-rext 0/4] RDMA/bnxt_re: Add QP rate limit support Kalesh AP
2026-01-16  9:18 ` [PATCH rdma-rext 1/4] IB/core: Extend rate limit support for RC QPs Kalesh AP
2026-01-16  9:18 ` [PATCH rdma-rext 2/4] RDMA/bnxt_re: Add support for QP rate limiting Kalesh AP
2026-01-16  9:18 ` [PATCH rdma-rext 3/4] RDMA/bnxt_re: Report packet pacing capabilities when querying device Kalesh AP
2026-01-16  9:18 ` [PATCH rdma-rext 4/4] RDMA/bnxt_re: Report QP rate limit in debugfs Kalesh AP
2026-01-25  4:17 ` [PATCH rdma-rext 0/4] RDMA/bnxt_re: Add QP rate limit support Kalesh Anakkur Purayil
2026-01-26 20:18   ` Leon Romanovsky
2026-01-28  7:03     ` Selvin Xavier
2026-01-28 12:17       ` Leon Romanovsky [this message]
2026-01-29  5:31         ` Selvin Xavier
2026-01-29  0:40       ` Jason Gunthorpe
2026-01-29  5:24         ` Selvin Xavier

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=20260128121733.GA40916@unreal \
    --to=leon@kernel.org \
    --cc=andrew.gospodarek@broadcom.com \
    --cc=jgg@ziepe.ca \
    --cc=kalesh-anakkur.purayil@broadcom.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=selvin.xavier@broadcom.com \
    /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.