Re: [PATCH net-next 1/2] dsa: tag_mxl862xx: set dsa_default_offload_fwd_mark()

[Jonas Gorski]

On Mon, Mar 9, 2026 at 1:02 AM Daniel Golle <daniel@xxxxxxxxxxxxxx> wrote:
>
> On Sun, Mar 08, 2026 at 09:15:42PM +0100, Jonas Gorski wrote:
> > On Sun, Mar 8, 2026 at 4:19 PM Daniel Golle <daniel@xxxxxxxxxxxxxx> wrote:
> > >
> > > On Sat, Mar 07, 2026 at 10:57:56AM +0100, Jonas Gorski wrote:
> > > > Hi,
> > > >
> > > > On 07/03/2026 04:30, Daniel Golle wrote:
> > > > > The MxL862xx offloads forwarding between bridged ports to the
> > > > > hardware, so set dsa_default_offload_fwd_mark() to avoid duplicate
> > > > > forwarding of packets of (eg. flooded) frames arriving at the CPU
> > > > > port.
> > > > >
> > > > > Signed-off-by: Daniel Golle <daniel@xxxxxxxxxxxxxx>
> > > > > ---
> > > > >  net/dsa/tag_mxl862xx.c | 2 ++
> > > > >  1 file changed, 2 insertions(+)
> > > > >
> > > > > diff --git a/net/dsa/tag_mxl862xx.c b/net/dsa/tag_mxl862xx.c
> > > > > index 01f2158682718..c02f69de61cbb 100644
> > > > > --- a/net/dsa/tag_mxl862xx.c
> > > > > +++ b/net/dsa/tag_mxl862xx.c
> > > > > @@ -92,6 +92,8 @@ static struct sk_buff *mxl862_tag_rcv(struct sk_buff *skb,
> > > > >     skb_pull_rcsum(skb, MXL862_HEADER_LEN);
> > > > >     dsa_strip_etype_header(skb, MXL862_HEADER_LEN);
> > > > >
> > > > > +   dsa_default_offload_fwd_mark(skb);
> > > >
> > > > Does the switch (by default) also flood link local traffic (e.g. STP, LACP,
> > > > etc)? If not, you should not mark these as fwd offloaded.
> > >
> > > No, it doesn't. Testing revealed that apparently it silently consumes them.
> > > I assume we'll need something like
> > >
> > > if (likely(!is_link_local_ether_addr(eth_hdr(skb)->h_dest)))
> > >     dsa_default_offload_fwd_mark(skb);
> > >
> > > similar to tag_brcm.c, right?
> >
> > Yepp, that would have been my suggestion :-)
>
> Ok, I'll do that then.
>
> >
> > > > Is there is a bit in the header that says whether a packet was flooded or
> > > > trapped that you can check?
> > >
> > > Earlier testing showed that frames arriving at the microcontroller under
> > > some conditions are relayed to the DSA CPU port -- and are destinguishable
> > > as such. However, there is not bit directly indicating whether the packet
> > > was (also) flooded already.
> >
> > So you know if they were copied to the cpu port due to some rules, but
> > not if they were snooped or trapped?
>
> I haven't found any details about that documented, and all I can say
> is that in some cases (some of the IEEE1588v2 frames generated by the
> local_termination.sh selftest, for example) the microcontroller seems
> to send an additional copy of the frame to the DSA CPU port using
> fields of the 8-byte tag which usually aren't used -- and that's why I
> even noticed them. The initial driver now merged upstream disabled the
> microcontroller SDMA and FMDA, effectively disconnecting it from the
> switch datapath, so it would shut up, and this effect can now longer
> be observed.
>
> Now, when testing if link-local frames would be forwarded I noticed
> that there is a set of default rules instatiated after reset which
> trap link-local frames to the microcontroller port. I suppose it could
> also be setup to snoop instead of trap by manually erasing these PCE
> rules and setting new ones instead. In this case, however, there would
> be no way to tell from the frame received on the DSA CPU port if the
> frame had also been sent to the microcontroller.

For dynamic configuration you would probably need to then check the
destination address, check if snooping or trapping is configured for
it, and then set (not) mark offloaded accordingly. While linux allows
you do dynamically configure some of the groups between
flooding/trapping, I'm not sure if this is propagated via dsa or even
switchdev.

I suggest sticking to the default of trapping and not marking as
offloaded. It's much easier to flood in software if needed than the
other way round.

Best regards,
Jonas