All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Geetha sowjanya <gakula@marvell.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	kuba@kernel.org, davem@davemloft.net, pabeni@redhat.com,
	edumazet@google.com, sgoutham@marvell.com, sbhatta@marvell.com,
	hkelam@marvell.com
Subject: Re: [net-next PATCH 1/3] octeontx2-af: Create BPIDs free pool
Date: Thu, 25 Jan 2024 11:33:36 +0000	[thread overview]
Message-ID: <20240125113336.GF217708@kernel.org> (raw)
In-Reply-To: <20240124055014.32694-2-gakula@marvell.com>

On Wed, Jan 24, 2024 at 11:20:12AM +0530, Geetha sowjanya wrote:
> Current code reserves 64 bpids for 64 LBK channels. But in most
> of the cases multiple LBK channels uses same bpid. This leads
> to inefficient use of bpids. Latest HW support configured multiple
> bpids per channel for other interface types (CGX). For better use
> of these bpids, this patch creates pool of free bpids from reserved
> LBK bpids. This free pool is used to allocate bpid on request for
> another interface like sso etc.
> 
> This patch also reduces the number of bpids for cgx interfaces to 8
> and adds proper error code
> 
> Signed-off-by: Geetha sowjanya <gakula@marvell.com>

Hi Geetha,

I have some suggestions for possible follow-up below.
That notwithstanding patch looks good to me.

Reviewed-by: Simon Horman <horms@kernel.org>

> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c
> index 66203a90f052..e1eae16b09b3 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c
> @@ -499,14 +499,84 @@ static void nix_interface_deinit(struct rvu *rvu, u16 pcifunc, u8 nixlf)
>  	rvu_cgx_disable_dmac_entries(rvu, pcifunc);
>  }
>  
> +#define NIX_BPIDS_PER_LMAC	8
> +#define NIX_BPIDS_PER_CPT	1
> +static int nix_setup_bpids(struct rvu *rvu, struct nix_hw *hw, int blkaddr)
> +{
> +	struct nix_bp *bp = &hw->bp;
> +	int err, max_bpids;
> +	u64 cfg;
> +
> +	cfg = rvu_read64(rvu, blkaddr, NIX_AF_CONST1);
> +	max_bpids = (cfg >> 12) & 0xFFF;

I don't think this needs to block progress of this patch,
but rather I'm providing this as a suggestion for a follow-up.

I think it would be nice to define a mask, created using GENMASK,
that names the register field (I don't know what it is).
And then uses FIELD_GET here.

Likewise for the 0xFFF below, and possibly elsewhere in this patch.

Further, in patch 2 I see the use of BIT(11) in the following patch.
And existing use of BIT(16) in this file.  I assume are register fields.
If so it would be nice to make #defines to name them too.

> +
> +	/* Reserve the BPIds for CGX and SDP */
> +	bp->cgx_bpid_cnt = rvu->hw->cgx_links * NIX_BPIDS_PER_LMAC;
> +	bp->sdp_bpid_cnt = rvu->hw->sdp_links * (cfg & 0xFFF);
> +	bp->free_pool_base = bp->cgx_bpid_cnt + bp->sdp_bpid_cnt +
> +			     NIX_BPIDS_PER_CPT;
> +	bp->bpids.max = max_bpids - bp->free_pool_base;

...

  reply	other threads:[~2024-01-25 11:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-24  5:50 [net-next PATCH 0/3] Dynamically allocate BPIDs Geetha sowjanya
2024-01-24  5:50 ` [net-next PATCH 1/3] octeontx2-af: Create BPIDs free pool Geetha sowjanya
2024-01-25 11:33   ` Simon Horman [this message]
2024-01-26  9:52     ` [EXT] " Geethasowjanya Akula
2024-01-24  5:50 ` [net-next PATCH 2/3] octeontx2-af: Add mbox to alloc/free BPIDs Geetha sowjanya
2024-01-25 11:33   ` Simon Horman
2024-01-24  5:50 ` [net-next PATCH 3/3] octeontx2-af: Cleanup loopback device checks Geetha sowjanya
2024-01-25 11:34   ` Simon Horman
2024-01-26  2:16 ` [net-next PATCH 0/3] Dynamically allocate BPIDs Jakub Kicinski
2024-01-26  9:54   ` [EXT] " Geethasowjanya Akula

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=20240125113336.GF217708@kernel.org \
    --to=horms@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gakula@marvell.com \
    --cc=hkelam@marvell.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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.