Re: [PATCH net-next v1] net: dsa: mv88e6xxx: Trap PTP traffic

[Kurt Kanzenbach <kurt@kmk-computers.de>]

On Sun Dec 12 2021, Tobias Waldekranz wrote:
>> Agreed. Some mechanism is required. Any idea how to implement it? In
>> case of PTP the management/policy entries should take precedence.
>
> One approach would be to create a cache containing all static ATU
> entries. That way we can easily track the owner of each entry. There are
> also major performance advantages of being able to update memberships of
> group entries without having to read the entry back from the ATU
> first. This is especially important once we start handling router ports
> correctly, in which case you have to update all active entries on every
> add/remove.
>
> Before going down that route though, I would suggest getting some
> initial feedback from Andrew.
>
> A complicating factor, no matter the implementation, is the relationship
> between the bridge MDB and all other consumers of ATU entries. As an
> example: If the driver first receives an MDB add for one of the L3 PTP
> groups, and then a user starts up ptp4l, the driver can't then go back
> to the bridge and say "remember that group entry that I said I loaded,
> well I have removed it now". So whatever implementation we choose, I
> think it needs to keep a shadow entry for the MDB that can be
> re-inserted if the corresponding management or policy entry is removed.
>
> You may simply want to allow all consumers to register any given group
> with the cache. The cache would then internally elect the "best" entry
> and install that to the ATU. Sort of what zebra/quagga/FRR does for
> dynamic routing. The priority would probably be something like:
>
> 1. Management entry
> 2. Policy entry
> 3. MDB entry
>
> This should still result in the proper forwarding of a registered groups
> that are shadowed by management or policy entries. The bridge would know
> (via skb->offload_fwd_mark) that the packet had not been forwarded in
> hardware and would fallback to software forwarding. If the policy entry
> was later removed (e.g. PTP was shut down) the MDB entry could be
> reinstalled and offloading resumed.

Thanks. This approach makes sense and should solve the problem at hand.

Thanks,
Kurt