On 2026-06-05 at 12:02:44, Ratheesh Kannoth (rkannoth@marvell.com) wrote:

Default CN20K NPC rule allocation now keys off the active MCAM keyword
width: use X4 with a bank-masked reference index when the silicon uses
X4 keys, and X2 with the raw index otherwise (replacing the previous
always-X2 / eidx + 1 behaviour).

In the AF flow-install path, flows that need more than 256 key bits
query the NPC profile; if the platform is fixed to X2 entries, fail
with -EOPNOTSUPP instead of requesting X4. Otherwise select X4 for the
MCAM alloc.

On the PF, cache and pass the profile kw_type from npc_get_pfl_info
through otx2_mcam_pfl_info_get(), and use it when allocating MCAM
entries for RSS/defaults and when installing ethtool flows on CN20K,
including masking the reference index for X4 slot layout.

Signed-off-by: Ratheesh Kannoth <redacted>

https://sashiko.dev/#/patchset/20260605063245.3553861-1-rkannoth%40marvell.com says

quoted

+static int otx2_mcam_pfl_info_get(struct otx2_nic *pfvf, u16 *x4_slots, u8 *kw_type)
 {
 	struct npc_get_pfl_info_rsp *rsp;
 	struct msg_req *req;
 	static struct {
 		bool is_set;
-		bool is_x2;
+		u8 kw_type;
 		u16 x4_slots;
 	} pfl_info;

This is a pre-existing issue, but does caching the hardware profile information
in this static structure lead to data races when multiple devices probe
concurrently?

Hw profile information is unique. AF process profile read mbox messages from PF serially. If first
PF updates this information, is_set flag will be set to true. Next PF can directly read this value
rather than sending an mbox request to AF. There wont be any race as values are same and updated serially.
Secondly this is a pre-existing issue, so we can add some hardeing logic (some locks) in a new series
after this patch series is merged.

+	u8 kw_type = 0;

quoted

+	u16 x4_slots;
 	u16 dft_idx;

 	ref = 0;

@@ -315,6 +319,16 @@ int otx2_mcam_entry_init(struct otx2_nic *pfvf)
 	if (!flow_cfg->def_ent)
 		return -ENOMEM;

This isn't a bug introduced by this patch, but does otx2_mcam_entry_init()
leak the def_ent array during repeated flow parameter updates?

Pre-existing issue, will address as a seperate patch after this series
is merged.