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

[netdev-bot+sashiko@kernel.org]

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