From: Ratheesh Kannoth <rkannoth@marvell.com>
To: <linux-kernel@vger.kernel.org>, <linux-rdma@vger.kernel.org>,
<netdev@vger.kernel.org>, <oss-drivers@corigine.com>
Cc: <akiyano@amazon.com>, <andrew+netdev@lunn.ch>,
<anthony.l.nguyen@intel.com>, <arkadiusz.kubalewski@intel.com>,
<brett.creeley@amd.com>, <darinzon@amazon.com>,
<davem@davemloft.net>, <donald.hunter@gmail.com>,
<edumazet@google.com>, <horms@kernel.org>, <idosch@nvidia.com>,
<ivecera@redhat.com>, <jiri@resnulli.us>, <kuba@kernel.org>,
<leon@kernel.org>, <mbloch@nvidia.com>,
<michael.chan@broadcom.com>, <pabeni@redhat.com>,
<pavan.chebbi@broadcom.com>, <petrm@nvidia.com>,
<Prathosh.Satish@microchip.com>, <przemyslaw.kitszel@intel.com>,
<saeedm@nvidia.com>, <sgoutham@marvell.com>, <tariqt@nvidia.com>,
<vadim.fedorenko@linux.dev>
Subject: Re: [PATCH v13 net-next 8/9] octeontx2: cn20k: Respect NPC MCAM X2/X4 profile in flows and DFT alloc
Date: Thu, 14 May 2026 09:44:51 +0530 [thread overview]
Message-ID: <agVMOzk9WhLvgXYW@rkannoth-OptiPlex-7090> (raw)
In-Reply-To: <20260511033923.1301976-9-rkannoth@marvell.com>
On 2026-05-11 at 09:09:22, 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;
>>
>> @@ -53,8 +52,8 @@ static int otx2_mcam_pfl_info_get(struct otx2_nic *pfvf, bool *is_x2,
>> */
>> mutex_lock(&pfvf->mbox.lock);
>> if (pfl_info.is_set) {
>This isn't a bug introduced by this patch, but caching device properties in
Since this is not a bug in this patch, not planning to address as part of this series.
>> @@ -164,6 +163,7 @@ int otx2_alloc_mcam_entries(struct otx2_nic *pfvf, u16 count)
>> u16 dft_idx = 0, x4_slots = 0;
>> int ent, allocated = 0, ref;
>> bool is_x2 = false;
>> + u8 kw_type = 0;
>> int rc;
>>
>> /* Free current ones and allocate new ones with requested count */
>> @@ -182,12 +182,14 @@ int otx2_alloc_mcam_entries(struct otx2_nic *pfvf, u16 count)
>> }
>>
>> if (is_cn20k(pfvf->pdev)) {
>> - rc = otx2_mcam_pfl_info_get(pfvf, &is_x2, &x4_slots);
>> + rc = otx2_mcam_pfl_info_get(pfvf, &x4_slots, &kw_type);
>> if (rc) {
>> netdev_err(pfvf->netdev, "Error to retrieve profile info\n");
>> return rc;
>> }
>This is an existing issue on this code path, but if otx2_mcam_pfl_info_get()
>fails here, or if otx2_get_dft_rl_idx() fails below, the function returns
>early without updating flow_cfg->max_flows.
Since this is not a bug in this patch, not planning to address as part of this series.
>> @@ -1174,15 +1192,14 @@ static int otx2_add_flow_msg(struct otx2_nic *pfvf, struct otx2_flow *flow)
>> #ifdef CONFIG_DCB
>> int vlan_prio, qidx, pfc_rule = 0;
>> #endif
>> + bool modify = false, is_x2;
>> int err, vf = 0, off, sz;
>> - bool modify = false;
>> u8 kw_type = 0;
>> u8 *src, *dst;
>> u16 x4_slots;
>> - bool is_x2;
>>
>> if (is_cn20k(pfvf->pdev)) {
>> - err = otx2_mcam_pfl_info_get(pfvf, &is_x2, &x4_slots);
>> + err = otx2_mcam_pfl_info_get(pfvf, &x4_slots, &kw_type);
>> if (err) {
>This is another existing issue in this function. If we trace further down
>in otx2_add_flow_msg() after the mailbox message is allocated:
> req = otx2_mbox_alloc_msg_npc_install_flow(&pfvf->mbox);
> ...
> vf = ethtool_get_flow_spec_ring_vf(ring_cookie);
> if (vf > pci_num_vf(pfvf->pdev)) {
> mutex_unlock(&pfvf->mbox.lock);
> return -EINVAL;
> }
>Does this error path abandon the partially constructed message in the mailbox
>queue? Would adding a call to otx2_mbox_reset(&pfvf->mbox.mbox, 0) before
>returning prevent this incomplete message from being transmitted during the
>next mailbox sync?
Since this is not a bug in this patch, not planning to address as part of this series.
>
> 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>
> ---
> .../ethernet/marvell/octeontx2/af/cn20k/npc.c | 21 ++++++--
> .../marvell/octeontx2/af/rvu_npc_fs.c | 12 ++++-
> .../marvell/octeontx2/nic/otx2_flows.c | 48 +++++++++++++------
> 3 files changed, 61 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
> index 88cfa6c67266..ff5baedbc122 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
> @@ -4438,10 +4438,16 @@ int npc_cn20k_dft_rules_alloc(struct rvu *rvu, u16 pcifunc)
> 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;
> + }
> +
> req.contig = false;
> req.ref_prio = NPC_MCAM_HIGHER_PRIO;
> - req.ref_entry = eidx;
> - req.kw_type = NPC_MCAM_KEY_X2;
> req.count = cnt;
> req.hdr.pcifunc = pcifunc;
>
> @@ -4471,11 +4477,18 @@ int npc_cn20k_dft_rules_alloc(struct rvu *rvu, u16 pcifunc)
> * as NPC_DFT_RULE_PRIO - 1 (higher hw priority)
> */
> req.contig = false;
> - req.kw_type = NPC_MCAM_KEY_X2;
> req.count = cnt;
> req.hdr.pcifunc = pcifunc;
> req.ref_prio = NPC_MCAM_LOWER_PRIO;
> - req.ref_entry = eidx + 1;
> +
> + 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;
> + }
> +
> ret = rvu_mbox_handler_npc_mcam_alloc_entry(rvu, &req, &rsp);
> if (ret) {
> dev_err(rvu->dev,
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c
> index 6ae9cdcb608b..d20eb0e47d7d 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c
> @@ -1671,9 +1671,11 @@ rvu_npc_alloc_entry_for_flow_install(struct rvu *rvu,
> {
> struct npc_mcam_alloc_entry_req entry_req;
> struct npc_mcam_alloc_entry_rsp entry_rsp;
> + struct npc_get_pfl_info_rsp rsp = { 0 };
> struct npc_get_num_kws_req kws_req;
> struct npc_get_num_kws_rsp kws_rsp;
> int off, kw_bits, rc;
> + struct msg_req req;
> u8 *src, *dst;
>
> if (!is_cn20k(rvu->pdev)) {
> @@ -1697,8 +1699,16 @@ rvu_npc_alloc_entry_for_flow_install(struct rvu *rvu,
> kw_bits = kws_rsp.kws * 64;
>
> *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;
> + }
>
> memset(&entry_req, 0, sizeof(entry_req));
> memset(&entry_rsp, 0, sizeof(entry_rsp));
> diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_flows.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_flows.c
> index 38cc539d724d..5dd0591fed99 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_flows.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_flows.c
> @@ -37,14 +37,13 @@ static void otx2_clear_ntuple_flow_info(struct otx2_nic *pfvf, struct otx2_flow_
> flow_cfg->max_flows = 0;
> }
>
> -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;
>
> @@ -53,8 +52,8 @@ static int otx2_mcam_pfl_info_get(struct otx2_nic *pfvf, bool *is_x2,
> */
> mutex_lock(&pfvf->mbox.lock);
> if (pfl_info.is_set) {
> - *is_x2 = pfl_info.is_x2;
> *x4_slots = pfl_info.x4_slots;
> + *kw_type = pfl_info.kw_type;
> mutex_unlock(&pfvf->mbox.lock);
> return 0;
> }
> @@ -79,16 +78,16 @@ static int otx2_mcam_pfl_info_get(struct otx2_nic *pfvf, bool *is_x2,
> return -EFAULT;
> }
>
> - *is_x2 = (rsp->kw_type == NPC_MCAM_KEY_X2);
> - if (*is_x2)
> - *x4_slots = 0;
> + pfl_info.kw_type = rsp->kw_type;
> + if (rsp->kw_type == NPC_MCAM_KEY_X2)
> + pfl_info.x4_slots = 0;
> else
> - *x4_slots = rsp->x4_slots;
> -
> - pfl_info.is_x2 = *is_x2;
> - pfl_info.x4_slots = *x4_slots;
> + pfl_info.x4_slots = rsp->x4_slots;
> pfl_info.is_set = true;
>
> + *x4_slots = pfl_info.x4_slots;
> + *kw_type = pfl_info.kw_type;
> +
> mutex_unlock(&pfvf->mbox.lock);
> return 0;
> }
> @@ -164,6 +163,7 @@ int otx2_alloc_mcam_entries(struct otx2_nic *pfvf, u16 count)
> u16 dft_idx = 0, x4_slots = 0;
> int ent, allocated = 0, ref;
> bool is_x2 = false;
> + u8 kw_type = 0;
> int rc;
>
> /* Free current ones and allocate new ones with requested count */
> @@ -182,12 +182,14 @@ int otx2_alloc_mcam_entries(struct otx2_nic *pfvf, u16 count)
> }
>
> if (is_cn20k(pfvf->pdev)) {
> - rc = otx2_mcam_pfl_info_get(pfvf, &is_x2, &x4_slots);
> + rc = otx2_mcam_pfl_info_get(pfvf, &x4_slots, &kw_type);
> if (rc) {
> netdev_err(pfvf->netdev, "Error to retrieve profile info\n");
> return rc;
> }
>
> + is_x2 = kw_type == NPC_MCAM_KEY_X2;
> +
> rc = otx2_get_dft_rl_idx(pfvf, &dft_idx);
> if (rc) {
> netdev_err(pfvf->netdev,
> @@ -289,6 +291,8 @@ int otx2_mcam_entry_init(struct otx2_nic *pfvf)
> struct npc_mcam_alloc_entry_rsp *rsp;
> int vf_vlan_max_flows, count;
> int rc, ref, prio, ent;
> + u8 kw_type = 0;
> + 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;
>
> + kw_type = NPC_MCAM_KEY_X2;
> + if (is_cn20k(pfvf->pdev)) {
> + rc = otx2_mcam_pfl_info_get(pfvf, &x4_slots, &kw_type);
> + if (rc) {
> + netdev_err(pfvf->netdev,
> + "Error to get pfl info\n");
> + return rc;
> + }
> + }
> +
> mutex_lock(&pfvf->mbox.lock);
>
> req = otx2_mbox_alloc_msg_npc_mcam_alloc_entry(&pfvf->mbox);
> @@ -324,6 +338,10 @@ int otx2_mcam_entry_init(struct otx2_nic *pfvf)
> }
>
> req->kw_type = NPC_MCAM_KEY_X2;
> + if (is_cn20k(pfvf->pdev) && kw_type == NPC_MCAM_KEY_X4) {
> + req->kw_type = NPC_MCAM_KEY_X4;
> + ref &= (x4_slots - 1);
> + }
> req->contig = false;
> req->count = count;
> req->ref_prio = prio;
> @@ -1174,15 +1192,14 @@ static int otx2_add_flow_msg(struct otx2_nic *pfvf, struct otx2_flow *flow)
> #ifdef CONFIG_DCB
> int vlan_prio, qidx, pfc_rule = 0;
> #endif
> + bool modify = false, is_x2;
> int err, vf = 0, off, sz;
> - bool modify = false;
> u8 kw_type = 0;
> u8 *src, *dst;
> u16 x4_slots;
> - bool is_x2;
>
> if (is_cn20k(pfvf->pdev)) {
> - err = otx2_mcam_pfl_info_get(pfvf, &is_x2, &x4_slots);
> + err = otx2_mcam_pfl_info_get(pfvf, &x4_slots, &kw_type);
> if (err) {
> netdev_err(pfvf->netdev,
> "Error to retrieve NPC profile info, pcifunc=%#x\n",
> @@ -1190,6 +1207,7 @@ static int otx2_add_flow_msg(struct otx2_nic *pfvf, struct otx2_flow *flow)
> return -EFAULT;
> }
>
> + is_x2 = kw_type == NPC_MCAM_KEY_X2;
> if (!is_x2) {
> err = otx2_prepare_flow_request(&flow->flow_spec,
> &treq);
> --
> 2.43.0
>
next prev parent reply other threads:[~2026-05-14 4:15 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-11 3:39 [PATCH v13 net-next 0/9] octeontx2-af: npc: Enhancements Ratheesh Kannoth
2026-05-11 3:39 ` [PATCH v13 net-next 1/9] octeontx2-af: npc: cn20k: debugfs enhancements Ratheesh Kannoth
2026-05-11 3:39 ` [PATCH v13 net-next 2/9] net/mlx5e: Reduce stack use reading PCIe congestion thresholds Ratheesh Kannoth
2026-05-11 9:02 ` Dragos Tatulea
2026-05-11 3:39 ` [PATCH v13 net-next 3/9] devlink: pass param values by pointer Ratheesh Kannoth
2026-05-11 8:52 ` Petr Machata
2026-05-12 1:43 ` Kiyanovski, Arthur
2026-05-11 3:39 ` [PATCH v13 net-next 4/9] devlink: Implement devlink param multi attribute nested data values Ratheesh Kannoth
2026-05-12 15:54 ` Ratheesh Kannoth
2026-05-14 3:58 ` Ratheesh Kannoth
2026-05-11 3:39 ` [PATCH v13 net-next 5/9] octeontx2-af: npc: cn20k: add subbank search order control Ratheesh Kannoth
2026-05-14 4:01 ` Ratheesh Kannoth
2026-05-11 3:39 ` [PATCH v13 net-next 6/9] octeontx2: cn20k: Coordinate default rules with NIX LF lifecycle Ratheesh Kannoth
2026-05-14 4:12 ` Ratheesh Kannoth
2026-05-11 3:39 ` [PATCH v13 net-next 7/9] octeontx2-af: npc: Support for custom KPU profile from filesystem Ratheesh Kannoth
2026-05-14 4:13 ` Ratheesh Kannoth
2026-05-11 3:39 ` [PATCH v13 net-next 8/9] octeontx2: cn20k: Respect NPC MCAM X2/X4 profile in flows and DFT alloc Ratheesh Kannoth
2026-05-14 4:14 ` Ratheesh Kannoth [this message]
2026-05-11 3:39 ` [PATCH v13 net-next 9/9] octeontx2-af: npc: cn20k: Allocate npc_priv and dstats dynamically Ratheesh Kannoth
2026-05-14 4:15 ` Ratheesh Kannoth
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=agVMOzk9WhLvgXYW@rkannoth-OptiPlex-7090 \
--to=rkannoth@marvell.com \
--cc=Prathosh.Satish@microchip.com \
--cc=akiyano@amazon.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=arkadiusz.kubalewski@intel.com \
--cc=brett.creeley@amd.com \
--cc=darinzon@amazon.com \
--cc=davem@davemloft.net \
--cc=donald.hunter@gmail.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=ivecera@redhat.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mbloch@nvidia.com \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=oss-drivers@corigine.com \
--cc=pabeni@redhat.com \
--cc=pavan.chebbi@broadcom.com \
--cc=petrm@nvidia.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=saeedm@nvidia.com \
--cc=sgoutham@marvell.com \
--cc=tariqt@nvidia.com \
--cc=vadim.fedorenko@linux.dev \
/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