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

[Ratheesh Kannoth]

On 2026-06-05 at 12:02:44, Ratheesh Kannoth (rkannoth@xxxxxxxxxxx) 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 <rkannoth@xxxxxxxxxxx>

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

>The commit message says this replaces the "previous always-X2 /
>eidx + 1 behaviour", but the pre-patch code used ref_entry = eidx
>in the higher-priority allocation and ref_entry = eidx + 1 only in
>the VF lower-priority fallback path.
>Is the commit message description of the prior behavior accurate?
>For the lower-priority fallback in the X2 branch, ref_entry now becomes
>eidx instead of eidx + 1, so the value passed to
>rvu_mbox_handler_npc_mcam_alloc_entry() changes for already-shipping X2
>CN20K silicon, separate from the X4 enablement.
>Was the prior eidx + 1 a deliberate offset (for example to step past
>the higher-priority slot reserved by the first allocation) or an
>off-by-one that is being corrected here?
>If it is a fix, would it make sense to split this into a standalone
>patch with a Fixes: tag so it can be backported and bisected
>independently of the X4 enablement, and could the rationale be added
>to the changelog?
eidx is the oorrect value as eidx + 1 may overflow. initially i submitted this patch
as bug fix, but simon said this is more than a bug fix, so this is part of net-next.