Netdev List
 help / color / mirror / Atom feed
From: Ratheesh Kannoth <rkannoth@marvell.com>
To: <linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>
Cc: <andrew+netdev@lunn.ch>, <davem@davemloft.net>,
	<donald.hunter@gmail.com>, <edumazet@google.com>,
	<horms@kernel.org>, <jiri@resnulli.us>, <kuba@kernel.org>,
	<pabeni@redhat.com>, <sgoutham@marvell.com>
Subject: Re: [PATCH v20 net-next 8/9] octeontx2: cn20k: Respect NPC MCAM X2/X4 profile in flows and DFT alloc
Date: Wed, 10 Jun 2026 11:01:55 +0530	[thread overview]
Message-ID: <aij2y-F4MQjMP71Z@rkannoth-OptiPlex-7090> (raw)
In-Reply-To: <20260609040453.711932-9-rkannoth@marvell.com>

On 2026-06-09 at 09:34:52, 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 <rkannoth@marvell.com>
> ---

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

>>  	pfvf = rvu_get_pfvf(rvu, pcifunc);
>>  	pfvf->hw_prio = NPC_DFT_RULE_PRIO;
>>
>> +	if (npc_priv.kw == NPC_MCAM_KEY_X4) {
>> +		req.kw_type = NPC_MCAM_KEY_X4;
>> +		req.ref_entry = eidx & (npc_priv.bank_depth - 1);
>> +	} else {
>> +		req.kw_type = NPC_MCAM_KEY_X2;
>> +		req.ref_entry = eidx;
>> +	}
>> +
>How is the X1/DYN profile expected to be handled here?  In
>include/.../mbox.h the enum sets:
DYN profile can request X2/X4 entry.

>
>>  	*kw_type = NPC_MCAM_KEY_X2;
>> -	if (kw_bits > 256)
>> +	if (kw_bits > 256) {
>> +		rvu_mbox_handler_npc_get_pfl_info(rvu, &req, &rsp);
>> +		if (rsp.kw_type == NPC_MCAM_KEY_X2) {
>> +			dev_err(rvu->dev,
>> +				"Only X2 entries are supported in X2 profile\n");
>> +			return -EOPNOTSUPP;
>> +		}
>> +
>>  		*kw_type = NPC_MCAM_KEY_X4;
>> +	}
>On a DYN-configured platform rsp.kw_type is NPC_MCAM_KEY_DYN (== 0), so
>the equality check rsp.kw_type == NPC_MCAM_KEY_X2 is false and the
>function proceeds to set *kw_type = NPC_MCAM_KEY_X4.
>The commit log says:
>    if the platform is fixed to X2 entries, fail with -EOPNOTSUPP
>    instead of requesting X4
>Is the intent for this rejection to also fire on DYN, or to only fire
>on X2?  As written, the dft-rule path in npc_cn20k_dft_rules_alloc()
>buckets DYN with X2, while this flow-install path treats DYN as X4-
>capable, so the same npc_priv.kw == DYN value drives different kw_type
>choices in the two callers.
>Could the patch handle DYN explicitly (or document why it cannot occur
>on the paths reached here) so the two sites agree?
This is intentional. if profile is X2, we can't alloc an X4 entry.

  reply	other threads:[~2026-06-10  5:32 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-09  4:04 [PATCH v20 net-next 0/9] octeontx2-af: npc: Enhancements Ratheesh Kannoth
2026-06-09  4:04 ` [PATCH v20 net-next 1/9] octeontx2-af: enforce single RVU AF probe Ratheesh Kannoth
2026-06-09  4:04 ` [PATCH v20 net-next 2/9] octeontx2-af: npc: cn20k: debugfs enhancements Ratheesh Kannoth
2026-06-10  4:19   ` Ratheesh Kannoth
2026-06-10  5:08   ` Ratheesh Kannoth
2026-06-09  4:04 ` [PATCH v20 net-next 3/9] devlink: heap-allocate param fill buffers in devlink_nl_param_fill Ratheesh Kannoth
2026-06-09  4:04 ` [PATCH v20 net-next 4/9] devlink: Implement devlink param multi attribute nested data values Ratheesh Kannoth
2026-06-09  4:04 ` [PATCH v20 net-next 5/9] octeontx2-af: npc: cn20k: add subbank search order control Ratheesh Kannoth
2026-06-10  4:28   ` Ratheesh Kannoth
2026-06-10  5:10   ` Ratheesh Kannoth
2026-06-09  4:04 ` [PATCH v20 net-next 6/9] octeontx2: cn20k: Coordinate default rules with NIX LF lifecycle Ratheesh Kannoth
2026-06-10  4:30   ` Ratheesh Kannoth
2026-06-10  4:31   ` Ratheesh Kannoth
2026-06-09  4:04 ` [PATCH v20 net-next 7/9] octeontx2-af: npc: Support for custom KPU profile from filesystem Ratheesh Kannoth
2026-06-10  5:24   ` Ratheesh Kannoth
2026-06-09  4:04 ` [PATCH v20 net-next 8/9] octeontx2: cn20k: Respect NPC MCAM X2/X4 profile in flows and DFT alloc Ratheesh Kannoth
2026-06-10  5:31   ` Ratheesh Kannoth [this message]
2026-06-09  4:04 ` [PATCH v20 net-next 9/9] octeontx2-af: npc: cn20k: Allocate npc_priv and dstats dynamically Ratheesh Kannoth
2026-06-10  4:40   ` Ratheesh Kannoth
2026-06-10  5:33   ` Ratheesh Kannoth
2026-06-13 23:30 ` [PATCH v20 net-next 0/9] octeontx2-af: npc: Enhancements patchwork-bot+netdevbpf

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=aij2y-F4MQjMP71Z@rkannoth-OptiPlex-7090 \
    --to=rkannoth@marvell.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=donald.hunter@gmail.com \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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