On Thu, Feb 25, 2021 at 08:25:23PM +0100, Tobias Waldekranz wrote: > On Sun, Feb 14, 2021 at 17:53, Vladimir Oltean <olte...@gmail.com> wrote: > > From: Vladimir Oltean <vladimir.olt...@nxp.com> > > > > DSA has gained the recent ability to deal gracefully with upper > > interfaces it cannot offload, such as the bridge, bonding or team > > drivers. When such uppers exist, the ports are still in standalone mode > > as far as the hardware is concerned. > > > > But when we deliver packets to the software bridge in order for that to > > do the forwarding, there is an unpleasant surprise in that the bridge > > will refuse to forward them. This is because we unconditionally set > > skb->offload_fwd_mark = true, meaning that the bridge thinks the frames > > were already forwarded in hardware by us. > > > > Since dp->bridge_dev is populated only when there is hardware offload > > for it, but not in the software fallback case, let's introduce a new > > helper that can be called from the tagger data path which sets the > > skb->offload_fwd_mark accordingly to zero when there is no hardware > > offload for bridging. This lets the bridge forward packets back to other > > interfaces of our switch, if needed. > > > > Signed-off-by: Vladimir Oltean <vladimir.olt...@nxp.com> > > --- > > For the generic and tag_dsa.c related changes: > > Reviewed-by: Tobias Waldekranz <tob...@waldekranz.com>
Actually with my switchdev_bridge_port_offload_notify() proposal, I don't think this patch is going to be needed at all. I think the bridge happily ignores a packet with skb->offload_fwd_mark = 1 if it comes from a port which has an offload_fwd_mark of 0, although I haven't tested that.
