From: Simon Horman <horms@kernel.org>
To: Hariprasad Kelam <hkelam@marvell.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
kuba@kernel.org, davem@davemloft.net, sgoutham@marvell.com,
gakula@marvell.com, jerinj@marvell.com, lcherian@marvell.com,
sbhatta@marvell.com, naveenm@marvell.com, edumazet@google.com,
pabeni@redhat.com
Subject: Re: [net-next Patch] octeontx2-af: map management port always to first PF
Date: Thu, 28 Mar 2024 14:58:19 +0000 [thread overview]
Message-ID: <20240328145819.GN403975@kernel.org> (raw)
In-Reply-To: <20240327160348.3023-1-hkelam@marvell.com>
On Wed, Mar 27, 2024 at 09:33:48PM +0530, Hariprasad Kelam wrote:
> The user can enable or disable any MAC block or a few ports of the
> block. The management port's interface name varies depending on the
> setup of the user if its not mapped to the first pf.
>
> The management port mapping is now configured to always connect to the
> first PF. This patch implements this change.
>
> Signed-off-by: Hariprasad Kelam <hkelam@marvell.com>
> Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com>
Hi Hariprasad and Sunil,
some feedback from my side.
> ---
> .../net/ethernet/marvell/octeontx2/af/mbox.h | 5 +-
> .../ethernet/marvell/octeontx2/af/rvu_cgx.c | 60 +++++++++++++++----
> 2 files changed, 53 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/mbox.h b/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
> index eb2a20b5a0d0..105d2e8f25df 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
> @@ -638,7 +638,10 @@ struct cgx_lmac_fwdata_s {
> /* Only applicable if SFP/QSFP slot is present */
> struct sfp_eeprom_s sfp_eeprom;
> struct phy_s phy;
> -#define LMAC_FWDATA_RESERVED_MEM 1021
> + u32 lmac_type;
> + u32 portm_idx;
> + u64 mgmt_port:1;
> +#define LMAC_FWDATA_RESERVED_MEM 1019
> u64 reserved[LMAC_FWDATA_RESERVED_MEM];
> };
>
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
> index 72e060cf6b61..446344801576 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
> @@ -118,15 +118,40 @@ static void rvu_map_cgx_nix_block(struct rvu *rvu, int pf,
> pfvf->nix_blkaddr = BLKADDR_NIX1;
> }
>
> -static int rvu_map_cgx_lmac_pf(struct rvu *rvu)
> +static bool rvu_cgx_is_mgmt_port(struct rvu *rvu, int cgx_id, int lmac_id)
> +{
> + struct cgx_lmac_fwdata_s *fwdata;
> +
> + fwdata = &rvu->fwdata->cgx_fw_data_usx[cgx_id][lmac_id];
> + if (fwdata->mgmt_port)
> + return true;
> +
> + return false;
nit: I think this could be more succinctly expressed as:
return !!fwdata->mgmt_port;
> +}
> +
> +static void __rvu_map_cgx_lmac_pf(struct rvu *rvu, int pf, int cgx, int lmac)
> {
> struct npc_pkind *pkind = &rvu->hw->pkind;
> + int numvfs, hwvfs;
> + int free_pkind;
> +
> + rvu->pf2cgxlmac_map[pf] = cgxlmac_id_to_bmap(cgx, lmac);
> + rvu->cgxlmac2pf_map[CGX_OFFSET(cgx) + lmac] = 1 << pf;
This isn't strictly related to this patch, but here
it seems implied that pf is not negative and <= 63, as
rvu->cgxlmac2pf_map[CGX_OFFSET(cgx) + lmac] is only 64 bits wide.
So firstly I wonder if pf should be unsigned
> + free_pkind = rvu_alloc_rsrc(&pkind->rsrc);
> + pkind->pfchan_map[free_pkind] = ((pf) & 0x3F) << 16;
Here pf is masked off so it is not more than 63.
But that seems to conflict with the assumption above that it is <= 63.
If there is a concern about it being larger, it should be
capped in the for loop that calls __rvu_map_cgx_lmac_pf() ?
> + rvu_map_cgx_nix_block(rvu, pf, cgx, lmac);
> + rvu->cgx_mapped_pfs++;
> + rvu_get_pf_numvfs(rvu, pf, &numvfs, &hwvfs);
> + rvu->cgx_mapped_vfs += numvfs;
> +}
> +
> +static int rvu_map_cgx_lmac_pf(struct rvu *rvu)
> +{
> int cgx_cnt_max = rvu->cgx_cnt_max;
> int pf = PF_CGXMAP_BASE;
> unsigned long lmac_bmap;
> - int size, free_pkind;
> int cgx, lmac, iter;
> - int numvfs, hwvfs;
> + int size;
>
> if (!cgx_cnt_max)
> return 0;
> @@ -155,6 +180,24 @@ static int rvu_map_cgx_lmac_pf(struct rvu *rvu)
> return -ENOMEM;
>
> rvu->cgx_mapped_pfs = 0;
> +
> + /* Map mgmt port always to first PF */
> + for (cgx = 0; cgx < cgx_cnt_max; cgx++) {
> + if (!rvu_cgx_pdata(cgx, rvu))
> + continue;
> + lmac_bmap = cgx_get_lmac_bmap(rvu_cgx_pdata(cgx, rvu));
> + for_each_set_bit(iter, &lmac_bmap, rvu->hw->lmac_per_cgx) {
> + lmac = cgx_get_lmacid(rvu_cgx_pdata(cgx, rvu), iter);
> + if (rvu_cgx_is_mgmt_port(rvu, cgx, lmac)) {
> + __rvu_map_cgx_lmac_pf(rvu, pf, cgx, lmac);
> + pf++;
> + goto non_mgmtport_mapping;
> + }
> + }
> + }
> +
> +non_mgmtport_mapping:
> +
> for (cgx = 0; cgx < cgx_cnt_max; cgx++) {
> if (!rvu_cgx_pdata(cgx, rvu))
> continue;
> @@ -162,14 +205,9 @@ static int rvu_map_cgx_lmac_pf(struct rvu *rvu)
> for_each_set_bit(iter, &lmac_bmap, rvu->hw->lmac_per_cgx) {
> lmac = cgx_get_lmacid(rvu_cgx_pdata(cgx, rvu),
> iter);
> - rvu->pf2cgxlmac_map[pf] = cgxlmac_id_to_bmap(cgx, lmac);
> - rvu->cgxlmac2pf_map[CGX_OFFSET(cgx) + lmac] = 1 << pf;
> - free_pkind = rvu_alloc_rsrc(&pkind->rsrc);
> - pkind->pfchan_map[free_pkind] = ((pf) & 0x3F) << 16;
> - rvu_map_cgx_nix_block(rvu, pf, cgx, lmac);
> - rvu->cgx_mapped_pfs++;
> - rvu_get_pf_numvfs(rvu, pf, &numvfs, &hwvfs);
> - rvu->cgx_mapped_vfs += numvfs;
> + if (rvu_cgx_is_mgmt_port(rvu, cgx, lmac))
> + continue;
> + __rvu_map_cgx_lmac_pf(rvu, pf, cgx, lmac);
> pf++;
> }
> }
There seems to be a fair amount of code duplication above.
If we can assume that there is always a management port,
then perhaps the following is simpler (compile tested only!).
And if not, I'd suggest moving the outermost for loop and everything
within it into a helper with a parameter such that it can handle
the (first?) management port on one invocation, and non management
ports on the next invocation.
static int rvu_map_cgx_lmac_pf(struct rvu *rvu)
{
struct npc_pkind *pkind = &rvu->hw->pkind;
int cgx_cnt_max = rvu->cgx_cnt_max;
- int pf = PF_CGXMAP_BASE;
+ int next_pf = PF_CGXMAP_BASE + 1;
unsigned long lmac_bmap;
int size, free_pkind;
int cgx, lmac, iter;
@@ -158,10 +167,20 @@ static int rvu_map_cgx_lmac_pf(struct rvu *rvu)
for (cgx = 0; cgx < cgx_cnt_max; cgx++) {
if (!rvu_cgx_pdata(cgx, rvu))
continue;
+
lmac_bmap = cgx_get_lmac_bmap(rvu_cgx_pdata(cgx, rvu));
for_each_set_bit(iter, &lmac_bmap, rvu->hw->lmac_per_cgx) {
+ int pf;
+
lmac = cgx_get_lmacid(rvu_cgx_pdata(cgx, rvu),
iter);
+
+ /* Always use first PF for management port */
+ if (rvu_cgx_is_mgmt_port(rvu, cgx, lmac))
+ pf = PF_CGXMAP_BASE;
+ else
+ pf = next_pf++;
+
rvu->pf2cgxlmac_map[pf] = cgxlmac_id_to_bmap(cgx, lmac);
rvu->cgxlmac2pf_map[CGX_OFFSET(cgx) + lmac] = 1 << pf;
free_pkind = rvu_alloc_rsrc(&pkind->rsrc);
next prev parent reply other threads:[~2024-03-28 14:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-27 16:03 [net-next Patch] octeontx2-af: map management port always to first PF Hariprasad Kelam
2024-03-28 14:58 ` Simon Horman [this message]
2024-04-01 8:38 ` ] " Hariprasad Kelam
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=20240328145819.GN403975@kernel.org \
--to=horms@kernel.org \
--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=naveenm@marvell.com \
--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;
as well as URLs for NNTP newsgroup(s).