Re: [PATCH v16 net-next 8/9] octeontx2: cn20k: Respect NPC MCAM X2/X4 profile in flows and DFT alloc

[Ratheesh Kannoth <rkannoth@marvell.com>]

On 2026-05-21 at 15:23:02, 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).
>
>> -static int otx2_mcam_pfl_info_get(struct otx2_nic *pfvf, bool *is_x2,
>> -				  u16 *x4_slots)
>> +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 since this patch expands the cached fields
>here, is it safe to use a function-local static struct for this profile
>information?
>Because pfl_info is static, it is shared globally across all NIC instances.
>However, access to it is protected by pfvf->mbox.lock further down in the
>function, which is a per-NIC instance lock.
>If multiple NIC instances (like multiple PFs or VFs) invoke this concurrently,
>they will acquire their own instance locks but race on this shared static
>structure. Could CPU or compiler instruction reordering cause one thread to
>observe pfl_info.is_set == true before x4_slots or kw_type are fully written?
>This could result in x4_slots == 0, causing underflow when calculating
>x4_slots - 1 later in otx2_alloc_mcam_entries().
>Additionally, does this mean the first probed device populates the cache for
>all devices, potentially forcing incorrect configurations if different hardware
>blocks have differing profiles?

These are AF attributes and is same for all PFs/VFs. Even multple PF/VFs request for these
features, AF will process these requests one by one. And all results of these requests will be same.