Hi,
On 19/11/2025 12:35 PM, Junfeng Guo wrote:
The HWS (Hardware Steering) IP tunnel detection implementation was not
recognizing IPIP tunnel types based on the next protocol value in the
outer IP header as specified by RFC 2003 (IP-in-IP) and RFC 2473
(IPv6 Encapsulation).
The issue was that the code treated all combinations of [IPv4|6] / [IPv4|6]
as IPIP tunnels, setting MLX5_FLOW_LAYER_IPIP flag regardless of the actual
protocol. While this happened to work for simple cases due to the fallback
classification, it violated RFC compliance and could cause issues with
protocol validation.
The fix adds RFC-compliant tunnel detection by
1. Checking the protocol field (IPPROTO_IPIP=4 or IPPROTO_IPV6=41) in the
outer IP header to determine tunnel type
2. Adding protocol mismatch validation to ensure outer protocol matches
inner header type
3. Correctly setting MLX5_FLOW_LAYER_IPV6_ENCAP for IPv6 encapsulation
The expected tunnel patterns are now:
- [ipv4 | ipv6] proto is 4 / ipv4 -> MLX5_FLOW_LAYER_IPIP
- [ipv4 | ipv6] proto is 41 / ipv6 -> MLX5_FLOW_LAYER_IPV6_ENCAP
For cases without protocol specification, fallback classification based on
inner header type is still supported.
Fixes: f66c7c3ab983 ("net/mlx5/hws: recognize IP-in-IP tunnel in definer layer")
Fixes: 4b7044562f59 ("net/mlx5: support IP-in-IP tunnel for all combinations")
Cc: [email protected]
Signed-off-by: Junfeng Guo <[email protected]>
Patch applied to next-net-mlx,
Kindest regards
Raslan Darawsheh
