On 2026-05-08 at 09:19:11, Ratheesh Kannoth ([email protected]) 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
pw-bot: changes-requested
>> -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;
>Does caching this profile information in a static structure cause a data
>race across concurrent device instances?
>The accesses to this shared cache are protected by
>mutex_lock(&pfvf->mbox.lock).
>Since this is a per-device instance lock, multiple network devices could
>concurrently acquire their own independent locks and read or write the shared
>pfl_info structure.
>Could this lack of synchronization lead to torn reads, such as reading x4_slots
>as 0 if the compiler reorders the write to is_set before x4_slots?
PF request as thru mbox, and mbox message handling is serialized in AF. So
there is
no scope for race.
