Re: Is it ok for switch TCAMs to depend on the bridge state?

[Jakub Kicinski <kuba@kernel.org>]

On Tue, 2 Nov 2021 11:03:53 +0000 Vladimir Oltean wrote:
> I don't have a clear picture in my mind about what is wrong. An airplane
> viewer might argue that the TCAM should be completely separate from the
> bridging service, but I'm not completely sure that this can be achieved
> in the aforementioned case with VLAN rewriting on ingress and on egress,
> it would seem more natural for these features to operate on the
> classified VLAN (which again, depends on VLAN awareness being turned on).
> Alternatively, one might argue that the deletion of a bridge interface
> should be vetoed, and so should the removal of a port from a bridge.
> But that is quite complicated, and doesn't answer questions such as
> "what should you do when you reboot".
> Alternatively, one might say that letting the user remove TCAM
> dependencies from the bridging service is fine, but the driver should
> have a way to also unoffload the tc-flower keys as long as the
> requirements are not satisfied. I think this is also difficult to
> implement.

Some random thoughts which may be completely nonsensical.

I thought we do have a way of indicating that flower rules are no
longer offloaded because tunnel rules need neigh to be resolved, 
but looking at the code it seems we only report some semblance of
offload status as part of stats.

For port removal maybe we can add a callback just for vetoing in case
the operation originates from user space?