Re: [PATCH net] octeontx2-af: fix inner LC ltype match for RSS flowkey

[netdev-bot+sashiko@kernel.org]

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

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

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).

- [Medium] The patch fixes an RSS regression but has no Fixes: tag.
- [Low] The commit message gets the layer and the failure mode wrong.

--

octeontx2-af: fix inner LC ltype match for RSS flowkey

This commit changes set_flowkey_fields() in rvu_nix.c so that the inner
IPv4 and IPv6 RSS flowkey fields use an exact ltype mask of 0xF instead
of NPC_LT_LC_IP_MATCH_MSK and NPC_LT_LC_IP6_MATCH_MSK. The outer IPv4
and IPv6 masks stay the same.

> octeontx2-af: fix inner LC ltype match for RSS flowkey
>
> Inner LC ltypes differ from outer LC ltypes, but RSS flowkey programming
> was using outer LC IP/IP6 ltype masks for inner IP keys.
>
> For inner IPv4/IPv6, match only the base IP ltype and do not include
> extension-header matches. Keep existing outer LC masks unchanged.

[Severity: Low]
Is this description accurate? In set_flowkey_fields(), the inner IP keys
are on layer LG, not LC:

	if (key_type == NIX_FLOW_KEY_TYPE_INNR_IPV6) {
		field->lid = NPC_LID_LG;
		field->ltype_match = NPC_LT_LG_TU_IP6;

LG also has no extension-header ltypes that could be included:

drivers/net/ethernet/marvell/octeontx2/af/npc.h:
enum npc_kpu_lg_ltype {
	NPC_LT_LG_TU_IP = 1,
	NPC_LT_LG_TU_IP6,
	NPC_LT_LG_TU_ARP,
	NPC_LT_LG_TU_ETHER_IN_NSH,
	NPC_LT_LG_CUSTOM0 = 0xE,
	NPC_LT_LG_CUSTOM1 = 0xF,
};

NPC_LT_LC_IP_MATCH_MSK and NPC_LT_LC_IP6_MATCH_MSK both evaluate to 0xE.

With match 2 and mask 0xE, INNR_IPV6 also matches NPC_LT_LG_TU_ARP (3).
The default KPU profile emits that ltype. As a result, tunnelled inner
ARP packets get 32 bytes at offset 8 of the ARP header hashed as an
IPv6 SIP/DIP.

With match 1 and mask 0xE, INNR_IPV4 either aliases with LG ltype 0 (no
inner layer) or never matches. Which one happens depends on how the
hardware applies the mask to LTYPE_MATCH. The hash code in
rvu_npc_hash.c compares (ltype & ltype_mask) against the match value,
which points to the never-match case.

Could the subject and body name the LG layer and describe these
effects, so it is clear which traffic was mis-hashed?

> This fixes inner-tunnel RSS key calculation and prevents mismatches in
> inner IP flow classification.
>
> Signed-off-by: kmahammadraf <kmahammadraf@marvell.com>
> Signed-off-by: Kiran Kumar K <kirankumark@marvell.com>

[Severity: Medium]
Should this patch carry Fixes: tags?

Before July 2024, set_flowkey_fields() set field->ltype_mask = 0xF after
the INNR_* override. The inner keys therefore matched NPC_LT_LG_TU_IP
and NPC_LT_LG_TU_IP6 exactly.

Two commits then changed that trailing assignment:

  e23ac1095b9e ("octeontx2-af: fix issue with IPv6 ext match for RSS")
  60795bbf0476 ("octeontx2-af: fix issue with IPv4 match for RSS")

They switched it to NPC_LT_LC_IP6_MATCH_MSK and NPC_LT_LC_IP_MATCH_MSK.
The assignment runs after the INNR_* override, so the 0xE mask was also
applied to the LG inner IP keys. This patch puts 0xF back for the inner
keys only, which reverses that regression.

Both commits carry Fixes: 41a7aa7b800d, so they are probably in stable
trees already. Would adding the following tags let this fix reach those
trees?

Fixes: 60795bbf0476 ("octeontx2-af: fix issue with IPv4 match for RSS")
Fixes: e23ac1095b9e ("octeontx2-af: fix issue with IPv6 ext match for RSS")

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