[PATCH net] octeontx2-af: Fix keep PF_FUNC match for AF TX rules in rep mode

[PATCH net] octeontx2-af: Fix keep PF_FUNC match for AF TX rules in rep mode

[kmahammadraf]

From: Aditya Thapliyal <athapliyal@marvell.com>

In representor mode, AF installs TX MCAM rules for representor traffic.
These TX rules must match on PF_FUNC to identify the correct target
function.

Currently, npc_update_tx_entry() clears PF_FUNC mask for AF-requested
rules. In rep_mode, that wildcard can make a TX rule match traffic for
other representors on the same TX interface, which can steer egress
traffic through the wrong rule.

Fix this by not clearing PF_FUNC mask for AF-installed TX rules when
rep_mode is enabled.

Fixes: 683645a2317e ("octeontx2-af: Add packet path between representor and VF")

Signed-off-by: kmahammadraf <kmahammadraf@marvell.com>
Signed-off-by: Aditya Thapliyal <athapliyal@marvell.com>

---
v2: https://lore.kernel.org/netdev/179292714974.3134.12015701378835588497@kernel.org/

    -Drop the channel-handling change from this patch.
    -Keep this patch focused on PF_FUNC mask handling in representor mode.
    -Clarify the representor TX symptom in the commit message.
---
 drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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 ec004ea5154c..4afd4a10cd64 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c
@@ -1396,7 +1396,7 @@ static int npc_update_tx_entry(struct rvu *rvu, struct rvu_pfvf *pfvf,
 	/* If AF is installing then do not care about
 	 * PF_FUNC in Send Descriptor
 	 */
-	if (is_pffunc_af(req->hdr.pcifunc))
+	if (is_pffunc_af(req->hdr.pcifunc) && !rvu->rep_mode)
 		mask = 0;
 
 	npc_update_entry(rvu, NPC_PF_FUNC, mdata, (__force u16)htons(target),
-- 
2.25.1

Re: [PATCH net] octeontx2-af: Fix keep PF_FUNC match for AF TX rules in rep mode

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

 - What hardware the change was tested on. For driver fixes please
   mention the device (and if relevant firmware version) used for
   testing, or say that the change was not tested on real hardware.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net] octeontx2-af: Fix keep PF_FUNC match for AF TX rules in rep mode

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 4 potential
issue(s) to consider.

Critical: 0 · High: 1 · Medium: 0 · Low: 3

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [High] The fix is incomplete.
- [Low] The commit message gets the scope of the bug wrong.
- [Low] The Signed-off-by chain is malformed.
- [Low] The comment above the changed condition in npc_update_tx_entry()
  (drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c) still reads…

--

octeontx2-af: Fix keep PF_FUNC match for AF TX rules in rep mode

When rep_mode is enabled, npc_update_tx_entry() no longer clears the
PF_FUNC mask for TX MCAM rules that the AF installs. Those rules now
match on the target PF_FUNC instead of wildcarding it.

> Currently, npc_update_tx_entry() clears PF_FUNC mask for AF-requested
> rules. In rep_mode, that wildcard can make a TX rule match traffic for
> other representors on the same TX interface, which can steer egress
> traffic through the wrong rule.

[Severity: Low]
Is this the full impact of the old behaviour?

For rte == true, rvu_rep_install_tx_rule() only sets req.vf. It never
sets req.features:

	if (rte) {
		req.vf = pcifunc;
	} else {

npc_update_flow() returns early when features is 0, so PF_FUNC was the
only key field for these entries. With mask = 0 the key was empty. Each
of these entries then matched all egress on the NIX TX interface from any
PF/VF, not just representor traffic.

In practice, the lowest-indexed TX entry would take all TX traffic and
loop it to LBK with the first representee's tag.

All representors also share one PF_FUNC (rvu->rep_pcifunc), so PF_FUNC
was never what told "other representors" apart.

Since this patch carries a Fixes: tag, could the commit message describe
the actual impact?

> Fixes: 683645a2317e ("octeontx2-af: Add packet path between representor and VF")
>
> Signed-off-by: kmahammadraf <kmahammadraf@marvell.com>
> Signed-off-by: Aditya Thapliyal <athapliyal@marvell.com>

[Severity: Low]
This isn't a bug, but the Signed-off-by chain looks off. The author is
Aditya Thapliyal, but the first Signed-off-by is from kmahammadraf and
there is no Co-developed-by tag.

Per Documentation/process/submitting-patches.rst, should there be a
Co-developed-by: line right before that Signed-off-by? Or should From:
name that person instead? The DCO also asks for a real name, and
kmahammadraf looks like a username.

There is also a blank line between the Fixes: tag and the Signed-off-by
block.

> 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 ec004ea5154cb..4afd4a10cd649 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c
> @@ -1396,7 +1396,7 @@ static int npc_update_tx_entry(struct rvu *rvu, struct rvu_pfvf *pfvf,
>  	/* If AF is installing then do not care about
>  	 * PF_FUNC in Send Descriptor
>  	 */
> -	if (is_pffunc_af(req->hdr.pcifunc))
> +	if (is_pffunc_af(req->hdr.pcifunc) && !rvu->rep_mode)

[Severity: Low]
This isn't a bug, but the comment above this condition still says the AF
does not care about PF_FUNC. With this change, AF-installed TX rules in
rep_mode match PF_FUNC exactly. Should the comment mention the rep_mode
exception?

>  		mask = 0;
>  
>  	npc_update_entry(rvu, NPC_PF_FUNC, mdata, (__force u16)htons(target),

[Severity: High]
Does this stop representor egress from going through the wrong TX rule
when there is more than one representee?

For rte == false, rvu_rep_install_tx_rule() uses the same target for
every representee. It relies on sq_id to tell them apart:

	} else {
		req.vf = rvu->rep_pcifunc;
		req.packet.sq_id = vlan_tci;
		req.mask.sq_id = 0xffff;
	}

req.features is never set, and npc_update_flow() returns right away when
there are no features:

	if (!features)
		return;

As far as I can tell, nothing in the AF uses sq_id. It is declared in
struct flow_msg in mbox.h and written in rvu_rep.c, and that is all.
There is no NPC key field for it either.

With this patch, PF_FUNC == htons(rep_pcifunc) is the only key field in
every rte == false entry, so all of these entries have the same key.
rvu_rep_install_mcam_rules() installs them at increasing indices, and
the lowest-indexed matching entry wins.

On the NIC side, rvu_rep_xmit() sends traffic for every representor from
the same representor PF. It picks only the SQ, based on rep_id:

	sq = &pf->qset.sq[rep->rep_id];

Wouldn't all of that traffic hit the first rte == false entry? It would
then get that entry's vtag0_def (the first representee's rep_id), and the
RX rule that matches on vlan_tci would deliver it to the first
representee.

The unused sq_id match dates back to 683645a2317e. Still, the commit
message says this patch stops a TX rule from matching traffic for other
representors and steering it through the wrong rule. That still looks
possible in the representor to representee direction.

Does the SQ id need to be added to the MCAM key to fix this, rather than
only changing the PF_FUNC mask?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261109105043.1986921-1-kmahammadraf%40marvell.com