All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Bharat Bhushan <bbhushan2@marvell.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	sgoutham@marvell.com, gakula@marvell.com, sbhatta@marvell.com,
	hkelam@marvell.com, davem@davemloft.net, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com, jerinj@marvell.com,
	lcherian@marvell.com, richardcochran@gmail.com
Subject: Re: [net-next,v2 3/8] octeontx2-af: Disable backpressure between CPT and NIX
Date: Mon, 13 May 2024 17:14:47 +0100	[thread overview]
Message-ID: <20240513161447.GR2787@kernel.org> (raw)
In-Reply-To: <20240513105446.297451-4-bbhushan2@marvell.com>

On Mon, May 13, 2024 at 04:24:41PM +0530, Bharat Bhushan wrote:
> NIX can assert backpressure to CPT on the NIX<=>CPT link.
> Keep the backpressure disabled for now. NIX block anyways
> handles backpressure asserted by MAC due to PFC or flow
> control pkts.
> 
> Signed-off-by: Bharat Bhushan <bbhushan2@marvell.com>

...

> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c

...

> @@ -592,8 +596,16 @@ int rvu_mbox_handler_nix_bp_disable(struct rvu *rvu,
>  	bp = &nix_hw->bp;
>  	chan_base = pfvf->rx_chan_base + req->chan_base;
>  	for (chan = chan_base; chan < (chan_base + req->chan_cnt); chan++) {
> -		cfg = rvu_read64(rvu, blkaddr, NIX_AF_RX_CHANX_CFG(chan));
> -		rvu_write64(rvu, blkaddr, NIX_AF_RX_CHANX_CFG(chan),
> +		/* CPT channel for a given link channel is always
> +		 * assumed to be BIT(11) set in link channel.
> +		 */
> +		if (cpt_link)
> +			chan_v = chan | BIT(11);
> +		else
> +			chan_v = chan;

Hi Bharat,

The chan_v logic above seems to appear twice in this patch.
I'd suggest adding a helper.

> +
> +		cfg = rvu_read64(rvu, blkaddr, NIX_AF_RX_CHANX_CFG(chan_v));
> +		rvu_write64(rvu, blkaddr, NIX_AF_RX_CHANX_CFG(chan_v),
>  			    cfg & ~BIT_ULL(16));
>  
>  		if (type == NIX_INTF_TYPE_LBK) {

...

> diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
> index 7ec99c8d610c..e9d2e039a322 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
> @@ -1705,6 +1705,31 @@ int otx2_nix_config_bp(struct otx2_nic *pfvf, bool enable)
>  }
>  EXPORT_SYMBOL(otx2_nix_config_bp);
>  
> +int otx2_nix_cpt_config_bp(struct otx2_nic *pfvf, bool enable)
> +{
> +	struct nix_bp_cfg_req *req;
> +
> +	if (enable)
> +		req = otx2_mbox_alloc_msg_nix_cpt_bp_enable(&pfvf->mbox);
> +	else
> +		req = otx2_mbox_alloc_msg_nix_cpt_bp_disable(&pfvf->mbox);
> +
> +	if (!req)
> +		return -ENOMEM;
> +
> +	req->chan_base = 0;
> +#ifdef CONFIG_DCB
> +	req->chan_cnt = pfvf->pfc_en ? IEEE_8021QAZ_MAX_TCS : 1;
> +	req->bpid_per_chan = pfvf->pfc_en ? 1 : 0;
> +#else
> +	req->chan_cnt =  1;
> +	req->bpid_per_chan = 0;
> +#endif

IMHO, inline #ifdefs reduce readability and reduce maintainability.

Would it be possible to either:

1. Include the pfc_en field in struct otx2_nic and make
   sure it is set to 0 if CONFIG_DCB is unset; or
2. Provide a wrapper that returns 0 if CONFIG_DCB is unset,
   otherwise pfvf->pfc_en.

I suspect 1 will have little downside and be easiest to implement.

> +
> +	return otx2_sync_mbox_msg(&pfvf->mbox);
> +}
> +EXPORT_SYMBOL(otx2_nix_cpt_config_bp);
> +
>  /* Mbox message handlers */
>  void mbox_handler_cgx_stats(struct otx2_nic *pfvf,
>  			    struct cgx_stats_rsp *rsp)

...

  reply	other threads:[~2024-05-13 16:14 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-13 10:54 [net-next,v2 0/8] cn10k-ipsec: Add outbound inline ipsec support Bharat Bhushan
2024-05-13 10:54 ` [net-next,v2 1/8] octeontx2-pf: map skb data as device writeable Bharat Bhushan
2024-05-13 10:54 ` [net-next,v2 2/8] octeontx2-pf: Move skb fragment map/unmap to common code Bharat Bhushan
2024-05-13 10:54 ` [net-next,v2 3/8] octeontx2-af: Disable backpressure between CPT and NIX Bharat Bhushan
2024-05-13 16:14   ` Simon Horman [this message]
2024-05-14  6:39     ` [EXTERNAL] " Bharat Bhushan
2024-05-14 10:41       ` Simon Horman
2024-05-14 11:26         ` Bharat Bhushan
2024-05-14 11:45           ` Simon Horman
2024-05-13 10:54 ` [net-next,v2 4/8] cn10k-ipsec: Initialize crypto hardware for outb inline ipsec Bharat Bhushan
2024-05-13 10:54 ` [net-next,v2 5/8] cn10k-ipsec: Add SA add/delete support " Bharat Bhushan
2024-05-13 16:51   ` Simon Horman
2024-05-14  6:52     ` [EXTERNAL] " Bharat Bhushan
2024-05-14 10:46       ` Simon Horman
2024-05-14  8:15   ` kernel test robot
2024-05-13 10:54 ` [net-next,v2 6/8] cn10k-ipsec: Process inline ipsec transmit offload Bharat Bhushan
2024-05-13 10:54 ` [net-next,v2 7/8] cn10k-ipsec: Allow inline ipsec offload for skb with SA Bharat Bhushan
2024-05-13 10:54 ` [net-next,v2 8/8] cn10k-ipsec: Enable outbound inline ipsec offload Bharat Bhushan
2024-05-13 12:22 ` [net-next,v2 0/8] cn10k-ipsec: Add outbound inline ipsec support Kalesh Anakkur Purayil

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=20240513161447.GR2787@kernel.org \
    --to=horms@kernel.org \
    --cc=bbhushan2@marvell.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gakula@marvell.com \
    --cc=hkelam@marvell.com \
    --cc=jerinj@marvell.com \
    --cc=kuba@kernel.org \
    --cc=lcherian@marvell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=richardcochran@gmail.com \
    --cc=sbhatta@marvell.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.