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;
...
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox