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

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?