All of lore.kernel.org
 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 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.