public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Cedric Jehasse <cedric.jehasse@luminex.be>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"andrew@lunn.ch" <andrew@lunn.ch>,
	"olteanv@gmail.com" <olteanv@gmail.com>,
	"edumazet@google.com" <edumazet@google.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [net-next,v4] net: dsa: mv88e6xxx: Add partial support for TCAM entries
Date: Fri, 27 Feb 2026 17:28:31 -0800	[thread overview]
Message-ID: <20260227172831.5ac5d09c@kernel.org> (raw)
In-Reply-To: <PR3P194MB15055DDD60A57C6D9023A277EA73A@PR3P194MB1505.EURP194.PROD.OUTLOOK.COM>

On Fri, 27 Feb 2026 09:44:54 +0000 Cedric Jehasse wrote:
> >> +     if (dissector->used_keys &
> >> +         ~(BIT_ULL(FLOW_DISSECTOR_KEY_BASIC) |
> >> +           BIT_ULL(FLOW_DISSECTOR_KEY_CONTROL) |
> >> +           BIT_ULL(FLOW_DISSECTOR_KEY_IPV4_ADDRS) |
> >> +           BIT_ULL(FLOW_DISSECTOR_KEY_IPV6_ADDRS))) {
> >> +             NL_SET_ERR_MSG_MOD(extack,
> >> +                                "Unsupported keys used");
> >> +             return -EOPNOTSUPP;
> >> +     }  
> >
> >FLOW_DISSECTOR_KEY_IPV6_ADDRS is included in the allowed keys bitmask,
> >but there is no code below to parse IPv6 addresses into the TCAM key.
> >
> >If a user creates a tc flower rule with IPv6 addresses, the rule passes
> >this validation check but the addresses are never programmed into the
> >TCAM. This would cause the hardware entry to match broader traffic than
> >intended.
> >
> >Looking at the code further down:
> >  
> >> +     if (addr_type == FLOW_DISSECTOR_KEY_IPV4_ADDRS) {
> >> +             struct flow_match_ipv4_addrs match;
> >> +
> >> +             flow_rule_match_ipv4_addrs(cls->rule, &match);
> >> +             mv88e6xxx_tcam_match_set(key, MV88E6XXX_IPV4_SRC_OFFSET,
> >> +                                      match.key->src,
> >> +                                      match.mask->src);
> >> +             mv88e6xxx_tcam_match_set(key, MV88E6XXX_IPV4_DST_OFFSET,
> >> +                                      match.key->dst,
> >> +                                      match.mask->dst);
> >> +     } else {
> >> +             NL_SET_ERR_MSG_MOD(extack,
> >> +                                "Unsupported address type");
> >> +             return -EOPNOTSUPP;
> >> +     }  
> >
> >The check at line 68-72 rejects non-IPv4 address types, but the IPv6 key
> >is still in the allowed keys bitmask at line 30. This creates a confusing
> >situation where IPv6 is both 'allowed' and 'unsupported'.
> >
> >Should FLOW_DISSECTOR_KEY_IPV6_ADDRS be removed from the allowed keys
> >until IPv6 parsing is implemented?  
> 
> At first FLOW_DISSECTOR_KEY_IPV6_ADDRS wasn't in the allowed keys bitmask, but
> creating ipv4 filter entries failed with -EOPNOTSUPP.
> Eg. when using the following tc command, the FLOW_DISSECTOR_KEY_IPV6_ADDRS bit
> is set in dissector->used_keys:
> tc filter add dev p1 ingress protocol ip flower skip_sw dst_ip 224.0.1.100 \
>     action trap
>     
> To make ipv4 filter entries work i had to add FLOW_DISSECTOR_KEY_IPV6_ADDRS to
> the allowed keys bitmask and check the addr_type instead.

I see. But that sounds like a bug / silliness in the core that should
be fixed. AFAICT it's due to the fact that the fields are a union and
FL_KEY_SET_IF_MASKED() ends up interpreting either being set as both :/

  reply	other threads:[~2026-02-28  1:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-25 13:37 [PATCH net-next v4] net: dsa: mv88e6xxx: Add partial support for TCAM entries Cedric Jehasse via B4 Relay
2026-02-27  3:55 ` [net-next,v4] " Jakub Kicinski
2026-02-27  9:44   ` Cedric Jehasse
2026-02-28  1:28     ` Jakub Kicinski [this message]
2026-03-02 13:36       ` Cedric Jehasse
2026-03-03  0:13         ` Jakub Kicinski
2026-02-27 14:06   ` Andrew Lunn
2026-02-27 23:55     ` Jakub Kicinski

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=20260227172831.5ac5d09c@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=cedric.jehasse@luminex.be \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    /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