Re: [PATCH v2 net 4/4] net: dsa: mv88e6xxx: Limit rsvd2cpu policy to user ports on 6393X

[Tobias Waldekranz <tobias@waldekranz.com>]

On tor, dec 19, 2024 at 16:52, Vladimir Oltean <olteanv@gmail.com> wrote:
> On Thu, Dec 19, 2024 at 04:42:08PM +0200, Vladimir Oltean wrote:
>> The other driver with tx_fwd_offload, sja1105,
>
> Correction: I forgot there is one more driver with tx_fwd_offload:
> vsc73xx, but that doesn't properly support link-local traffic yet at all,
> according to the vsc73xx_port_stp_state_set() comment. So we can ignore it.
>
>> is going to drop any
>> packet coming from the host_port which isn't sent through a management
>> route (set up by sja1105_defer_xmit()). So it's more than likely bugged.
>> 
>> We can't fix this from sja1105_xmit() by reordering sja1105_imprecise_xmit()
>> and sja1105_defer_xmit(). It's not just the order of operations in the
>> tagger. It's the fact that the bridge thinks it doesn't need to clone
>> the skb, and it does.
>
> Another correction: we could probably make a best-effort attempt to
> honor skb->offload_fwd_mark in sja1105_mgmt_xmit() by setting mgmt_route.destports
> to the bit mask of all other ports that are in dsa_port_bridge_dev_get(dp).
> But it gets unpleasantly difficult to manage, plus I think we still don't
> get MAC SA learning from these packets.
>
>> So yes, it's probably best to exclude link-local from skb->offload_fwd_mark.
>
> So I'm still of this opinion :) I think the effort to handle the corner
> cases isn't worth it relative to the benefit of offloading the forwarding
> of slow protocols.

Agreed. I will remove this patch in v3 and replace it with a general
patch for the bridge instead. Thanks!