netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Subbaraya Sundeep <sbhatta@marvell.com>
To: Simon Horman <horms@kernel.org>
Cc: <andrew+netdev@lunn.ch>, <davem@davemloft.net>,
	<edumazet@google.com>, <kuba@kernel.org>, <pabeni@redhat.com>,
	<gakula@marvell.com>, <hkelam@marvell.com>,
	<bbhushan2@marvell.com>, <jerinj@marvell.com>,
	<lcherian@marvell.com>, <sgoutham@marvell.com>,
	<netdev@vger.kernel.org>
Subject: Re: [net-next PATCH v3 07/11] octeontx2-pf: Initialize cn20k specific aura and pool contexts
Date: Thu, 24 Jul 2025 14:54:55 +0000	[thread overview]
Message-ID: <aIJJP1OmYAk5Y6PE@opensource> (raw)
In-Reply-To: <20250722170344.GS2459@horms.kernel.org>

Hi Simon,

On 2025-07-22 at 17:03:44, Simon Horman (horms@kernel.org) wrote:
> On Thu, Jul 17, 2025 at 10:37:39PM +0530, Subbaraya Sundeep wrote:
> > From: Linu Cherian <lcherian@marvell.com>
> > 
> > With new CN20K NPA pool and aura contexts supported in AF
> > driver this patch modifies PF driver to use new NPA contexts.
> > Implement new hw_ops for intializing aura and pool contexts
> > for all the silicons.
> > 
> > Signed-off-by: Linu Cherian <lcherian@marvell.com>
> > Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
> 
> ...
> 
> > @@ -250,3 +239,170 @@ int cn20k_register_pfvf_mbox_intr(struct otx2_nic *pf, int numvfs)
> >  
> >  	return 0;
> >  }
> > +
> > +#define RQ_BP_LVL_AURA   (255 - ((85 * 256) / 100)) /* BP when 85% is full */
> > +
> > +static int cn20k_aura_aq_init(struct otx2_nic *pfvf, int aura_id,
> > +			      int pool_id, int numptrs)
> > +{
> > +	struct npa_cn20k_aq_enq_req *aq;
> > +	struct otx2_pool *pool;
> > +	int err;
> > +
> > +	pool = &pfvf->qset.pool[pool_id];
> > +
> > +	/* Allocate memory for HW to update Aura count.
> > +	 * Alloc one cache line, so that it fits all FC_STYPE modes.
> > +	 */
> > +	if (!pool->fc_addr) {
> > +		err = qmem_alloc(pfvf->dev, &pool->fc_addr, 1, OTX2_ALIGN);
> > +		if (err)
> > +			return err;
> > +	}
> > +
> > +	/* Initialize this aura's context via AF */
> > +	aq = otx2_mbox_alloc_msg_npa_cn20k_aq_enq(&pfvf->mbox);
> > +	if (!aq) {
> > +		/* Shared mbox memory buffer is full, flush it and retry */
> > +		err = otx2_sync_mbox_msg(&pfvf->mbox);
> > +		if (err)
> > +			return err;
> > +		aq = otx2_mbox_alloc_msg_npa_cn20k_aq_enq(&pfvf->mbox);
> > +		if (!aq)
> > +			return -ENOMEM;
> > +	}
> > +
> > +	aq->aura_id = aura_id;
> > +
> > +	/* Will be filled by AF with correct pool context address */
> > +	aq->aura.pool_addr = pool_id;
> > +	aq->aura.pool_caching = 1;
> > +	aq->aura.shift = ilog2(numptrs) - 8;
> > +	aq->aura.count = numptrs;
> > +	aq->aura.limit = numptrs;
> > +	aq->aura.avg_level = 255;
> > +	aq->aura.ena = 1;
> > +	aq->aura.fc_ena = 1;
> > +	aq->aura.fc_addr = pool->fc_addr->iova;
> > +	aq->aura.fc_hyst_bits = 0; /* Store count on all updates */
> > +
> > +	/* Enable backpressure for RQ aura */
> > +	if (aura_id < pfvf->hw.rqpool_cnt && !is_otx2_lbkvf(pfvf->pdev)) {
> > +		aq->aura.bp_ena = 0;
> > +		/* If NIX1 LF is attached then specify NIX1_RX.
> > +		 *
> > +		 * Below NPA_AURA_S[BP_ENA] is set according to the
> > +		 * NPA_BPINTF_E enumeration given as:
> > +		 * 0x0 + a*0x1 where 'a' is 0 for NIX0_RX and 1 for NIX1_RX so
> > +		 * NIX0_RX is 0x0 + 0*0x1 = 0
> > +		 * NIX1_RX is 0x0 + 1*0x1 = 1
> > +		 * But in HRM it is given that
> > +		 * "NPA_AURA_S[BP_ENA](w1[33:32]) - Enable aura backpressure to
> > +		 * NIX-RX based on [BP] level. One bit per NIX-RX; index
> > +		 * enumerated by NPA_BPINTF_E."
> > +		 */
> > +		if (pfvf->nix_blkaddr == BLKADDR_NIX1)
> > +			aq->aura.bp_ena = 1;
> > +#ifdef CONFIG_DCB
> > +		aq->aura.bpid = pfvf->bpid[pfvf->queue_to_pfc_map[aura_id]];
> > +#else
> > +		aq->aura.bpid = pfvf->bpid[0];
> > +#endif
> 
> >From a build coverage point of view it is a shame that we can't use
> something like this here (because queue_to_pfc_map doesn't exist
> if CONFIG_DCB isn't enabled).
> 
> 		bpid_idx = IS_ENABLED(CONFIG_DCB) ? ...;
> 
> But I do wonder if somehow it's nicer to constrain the #ifdef to an
> as-small-as-possible helper. Something like this (compile tested only):
> 
> @@ -242,6 +242,15 @@ int cn20k_register_pfvf_mbox_intr(struct otx2_nic *pf, int numvfs)
>  
>  #define RQ_BP_LVL_AURA   (255 - ((85 * 256) / 100)) /* BP when 85% is full */
>  
> +static u8 cn20k_aura_bpid_idx(struct otx2_nic *pfvf, int aura_id)
> +{
> +#ifdef CONFIG_DCB
> +	return pfvf->queue_to_pfc_map[aura_id];
> +#else
> +	return 0;
> +#endif
> +}
> +
>  static int cn20k_aura_aq_init(struct otx2_nic *pfvf, int aura_id,
>  			      int pool_id, int numptrs)
>  {
> @@ -289,6 +298,7 @@ static int cn20k_aura_aq_init(struct otx2_nic *pfvf, int aura_id,
>  	/* Enable backpressure for RQ aura */
>  	if (aura_id < pfvf->hw.rqpool_cnt && !is_otx2_lbkvf(pfvf->pdev)) {
>  		aq->aura.bp_ena = 0;
> +		u8 bpid_idx;
>  		/* If NIX1 LF is attached then specify NIX1_RX.
>  		 *
>  		 * Below NPA_AURA_S[BP_ENA] is set according to the
> @@ -303,11 +313,9 @@ static int cn20k_aura_aq_init(struct otx2_nic *pfvf, int aura_id,
>  		 */
>  		if (pfvf->nix_blkaddr == BLKADDR_NIX1)
>  			aq->aura.bp_ena = 1;
> -#ifdef CONFIG_DCB
> -		aq->aura.bpid = pfvf->bpid[pfvf->queue_to_pfc_map[aura_id]];
> -#else
> -		aq->aura.bpid = pfvf->bpid[0];
> -#endif
> +
> +		bpid_idx = cn20k_aura_bpid_idx(pfvf, aura_id);
> +		aq->aura.bpid = pfvf->bpid[bpid_idx];
>  
Okay will modify as per your suggestion.

Thanks,
Sundeep
>  		/* Set backpressure level for RQ's Aura */
>  		aq->aura.bp = RQ_BP_LVL_AURA;
> 
> > +
> > +		/* Set backpressure level for RQ's Aura */
> > +		aq->aura.bp = RQ_BP_LVL_AURA;
> > +	}
> > +
> > +	/* Fill AQ info */
> > +	aq->ctype = NPA_AQ_CTYPE_AURA;
> > +	aq->op = NPA_AQ_INSTOP_INIT;
> > +
> > +	return 0;
> > +}
> 
> ...

  reply	other threads:[~2025-07-24 14:55 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-17 17:07 [net-next PATCH v3 00/11] Add CN20K NIX and NPA contexts Subbaraya Sundeep
2025-07-17 17:07 ` [net-next PATCH v3 01/11] octeontx2-af: Simplify context writing and reading to hardware Subbaraya Sundeep
2025-07-22 16:27   ` Simon Horman
2025-07-22 16:29     ` Simon Horman
2025-07-24 14:50       ` Subbaraya Sundeep
2025-07-17 17:07 ` [net-next PATCH v3 02/11] octeontx2-af: Add cn20k NIX block contexts Subbaraya Sundeep
2025-07-17 17:07 ` [net-next PATCH v3 03/11] octeontx2-af: Extend debugfs support for cn20k NIX Subbaraya Sundeep
2025-07-22 16:40   ` Simon Horman
2025-07-24 14:51     ` Subbaraya Sundeep
2025-07-17 17:07 ` [net-next PATCH v3 04/11] octeontx2-af: Add cn20k NPA block contexts Subbaraya Sundeep
2025-07-17 17:07 ` [net-next PATCH v3 05/11] octeontx2-af: Extend debugfs support for cn20k NPA Subbaraya Sundeep
2025-07-17 17:07 ` [net-next PATCH v3 06/11] octeontx2-af: Skip NDC operations for cn20k Subbaraya Sundeep
2025-07-17 17:07 ` [net-next PATCH v3 07/11] octeontx2-pf: Initialize cn20k specific aura and pool contexts Subbaraya Sundeep
2025-07-22  0:40   ` Jakub Kicinski
2025-07-22 17:03   ` Simon Horman
2025-07-24 14:54     ` Subbaraya Sundeep [this message]
2025-07-17 17:07 ` [net-next PATCH v3 08/11] octeontx2-pf: Initialize new NIX SQ context for cn20k Subbaraya Sundeep
2025-07-22 17:06   ` Simon Horman
2025-07-24 14:57     ` Subbaraya Sundeep
2025-07-17 17:07 ` [net-next PATCH v3 09/11] octeontx2-af: Accommodate more bandwidth profiles " Subbaraya Sundeep
2025-07-22 17:08   ` Simon Horman
2025-07-24 14:58     ` Subbaraya Sundeep
2025-07-17 17:07 ` [net-next PATCH v3 10/11] octeontx2-af: Display new bandwidth profiles too in debugfs Subbaraya Sundeep
2025-07-17 17:07 ` [net-next PATCH v3 11/11] octeontx2-pf: Use new bandwidth profiles in receive queue Subbaraya Sundeep

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=aIJJP1OmYAk5Y6PE@opensource \
    --to=sbhatta@marvell.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=bbhushan2@marvell.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gakula@marvell.com \
    --cc=hkelam@marvell.com \
    --cc=horms@kernel.org \
    --cc=jerinj@marvell.com \
    --cc=kuba@kernel.org \
    --cc=lcherian@marvell.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sgoutham@marvell.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).