Re: [PATCH net-next] net: mscc: ocelot: deal with problematic MAC_ETYPE VCAP IS2 rules

[Ido Schimmel <idosch@idosch.org>]

On Sun, Apr 19, 2020 at 09:33:07AM +0200, Allan W. Nielsen wrote:
> Hi,
> 
> Sorry I did not manage to provide feedback before it was merged (I will
> need to consult some of my colleagues Monday before I can provide the
> foll feedback).
> 
> There are many good things in this patch, but it is not only good.
> 
> The problem is that these TCAMs/VCAPs are insanely complicated and it is
> really hard to make them fit nicely into the existing tc frame-work
> (being hard does not mean that we should not try).
> 
> In this patch, you try to automatic figure out who the user want the
> TCAM to be configured. It works for 1 use-case but it breaks others.
> 
> Before this patch you could do a:
>     tc filter add dev swp0 ingress protocol ipv4 \
>             flower skip_sw src_ip 10.0.0.1 action drop
>     tc filter add dev swp0 ingress \
>             flower skip_sw src_mac 96:18:82:00:04:01 action drop
> 
> But the second rule would not apply to the ICMP over IPv4 over Ethernet
> packet, it would however apply to non-IP packets.
> 
> With this patch it not possible. Your use-case is more common, but the
> other one is not unrealistic.
> 
> My concern with this, is that I do not think it is possible to automatic
> detect how these TCAMs needs to be configured by only looking at the
> rules installed by the user. Trying to do this automatic, also makes the
> TCAM logic even harder to understand for the user.
> 
> I would prefer that we by default uses some conservative default
> settings which are easy to understand, and then expose some expert
> settings in the sysfs, which can be used to achieve different
> behavioral.
> 
> Maybe forcing MAC_ETYPE matches is the most conservative and easiest to
> understand default.
> 
> But I do seem to recall that there is a way to allow matching on both
> SMAC and SIP (your original motivation). This may be a better default
> (despite that it consumes more TCAM resources). I will follow up and
> check if this is possible.
> 
> Vladimir (and anyone else whom interested): would you be interested in
> spending some time discussion the more high-level architectures and
> use-cases on how to best integrate this TCAM architecture into the Linux
> kernel. Not sure on the outlook for the various conferences, but we
> could arrange some online session to discuss this.

Not sure I completely understand the difficulties you are facing, but it
sounds similar to a problem we had in mlxsw. You might want to look into
"chain templates" [1] in order to restrict the keys that can be used
simultaneously.

I don't mind participating in an online discussion if you think it can
help.

[1] https://github.com/Mellanox/mlxsw/wiki/ACLs#chain-templates