netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Cc: Tatyana Nikolova <tatyana.e.nikolova@intel.com>,
	jiri@resnulli.us, intel-wired-lan@lists.osuosl.org,
	linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
	anthony.l.nguyen@intel.com, Jakub Kicinski <kuba@kernel.org>,
	Mohammad Heib <mheib@redhat.com>
Subject: Re: [iwl-next] ice, irdma: Add rdma_qp_limits_sel devlink parameter for irdma
Date: Wed, 10 Sep 2025 15:13:17 +0300	[thread overview]
Message-ID: <20250910121317.GQ341237@unreal> (raw)
In-Reply-To: <33d327a0-72d3-4775-8842-6c4ceaff41e2@intel.com>

On Wed, Sep 10, 2025 at 09:41:14AM +0200, Przemek Kitszel wrote:
> On 9/9/25 14:20, Leon Romanovsky wrote:
> > On Thu, Sep 04, 2025 at 02:57:19PM -0500, Tatyana Nikolova wrote:
> > > Add a devlink parameter to switch between different QP resource profiles
> > > (max number of QPs) supported by irdma for Intel Ethernet 800 devices. The
> > > rdma_qp_limits_sel is translated into an index in the rsrc_limits_table to
> > > select a power of two number between 1 and 256 for max supported QPs (1K-256K).
> > > To reduce the irdma memory footprint, set the rdma_qp_limits_sel default value
> > > to 1 (max 1K QPs).
> > > 
> > > Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> > > Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
> > > ---
> > > Since the changes to irdma are minor, this is targeted to iwl-next/net-next.
> > 
> > <...>
> > 
> > >   #define DEVLINK_LOCAL_FWD_DISABLED_STR "disabled"
> > >   #define DEVLINK_LOCAL_FWD_ENABLED_STR "enabled"
> > >   #define DEVLINK_LOCAL_FWD_PRIORITIZED_STR "prioritized"
> > > @@ -1621,6 +1723,7 @@ enum ice_param_id {
> > >   	ICE_DEVLINK_PARAM_ID_BASE = DEVLINK_PARAM_GENERIC_ID_MAX,
> > >   	ICE_DEVLINK_PARAM_ID_TX_SCHED_LAYERS,
> > >   	ICE_DEVLINK_PARAM_ID_LOCAL_FWD,
> > > +	ICE_DEVLINK_PARAM_ID_RDMA_QP_LIMITS_SEL,
> > >   };
> > 
> > I was under impression that driver-specific devlink knobs are not
> > allowed. Was this limitation changed for Intel?
> 
> I'm not aware of such limitation.

It is possible that my impression was wrong.

> It's always better to have generic params, but some knobs are not likely
> to be reused; anyway it would be easy to convert into generic.

Unlikely, you will need to keep old parameter and new at the same time
for backward compatibility reasons.

> 
> To have this particular param more generic-ready, we have converted from
> our internal format (values were 0...7, mapped into some powers of two)
> to what one could imagine other drivers would like to add at some point
> (perhaps multiplying the user-provided value by 1K is unnecessarily
> complicating adoption for small NICs, IDK?).
> 
> Do you believe this should be switched to generic now (instead of when
> there is a future user)?
> What about a name (this should be kept forever)?

mlx5 has .log_max_qp in mlx5_profile which looks similar to what you are
proposing here, so RDMA_QP_LIMITS sounds fine to me.

> 
> side note:
> We are also going to add yet another param, now used only by intel, but
> we do so as a generic one: "max number of MAC addrs for VF in i40e", see
> https://lore.kernel.org/intel-wired-lan/20250907100454.193420-1-mheib@redhat.com/T/#t
> 
> 
> > 
> > Thanks
> 

  reply	other threads:[~2025-09-10 12:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-04 19:57 [iwl-next] ice, irdma: Add rdma_qp_limits_sel devlink parameter for irdma Tatyana Nikolova
2025-09-09 12:20 ` Leon Romanovsky
2025-09-10  7:41   ` Przemek Kitszel
2025-09-10 12:13     ` Leon Romanovsky [this message]
2025-09-11 19:51       ` Przemek Kitszel

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=20250910121317.GQ341237@unreal \
    --to=leon@kernel.org \
    --cc=anthony.l.nguyen@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mheib@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=tatyana.e.nikolova@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).