From: Andrew Lunn <andrew@lunn.ch>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: "Jan Hoffmann" <jan@3e8.eu>, "Arınç ÜNAL" <arinc.unal@arinc9.com>,
netdev@vger.kernel.org, "Florian Fainelli" <f.fainelli@gmail.com>,
openwrt-devel@lists.openwrt.org,
"Sander Vanheule" <sander@svanheule.net>,
erkin.bozoglu@xeront.com
Subject: Re: [PATCH 0/6] realtek: fix management of mdb entries
Date: Tue, 21 Mar 2023 20:02:06 +0100 [thread overview]
Message-ID: <b6223705-e34d-4f0e-8d42-021fa467d773@lunn.ch> (raw)
In-Reply-To: <20230321172415.3ccdi4j226d5qa7h@skbuf>
> > If the DSA subsystem could handle the "merging" instead and also call
> > port_mdb_add/port_mdb_del as appropriate for multicast router ports, the
> > individual drivers wouldn't have to deal with this particular issue at all.
> >
> > > As a way to fix a bug quickly and get correct behavior, I guess there's
> > > also the option of stopping to process multicast packets in hardware,
> > > and configure the switch to always send any multicast to the CPU port
> > > only. As long as the tagger knows to leave skb->offload_fwd_mark unset,
> > > the bridge driver should know how to deal with those packets in
> > > software, and forward them only to whom is interested. But the drawback
> > > is that there is no forwarding acceleration involved. Maybe DSA should
> > > have done that from the get go for drivers which didn't care about
> > > multicast in particular, instead of ending up with this current situation
> > > which appears to be slightly chaotic.
> >
> > Thanks,
> > Jan
>
> Andrew, Florian, do you have any additional comments here?
I've no real experience with this either. But it sounds like this
merging should be pulled up into the bridge, if all switchdev drivers
need it.
Andrew
next prev parent reply other threads:[~2023-03-21 19:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230303214846.410414-1-jan@3e8.eu>
[not found] ` <dd0c8abb-ebb7-8ea5-12ed-e88b5e310a28@arinc9.com>
2023-03-06 13:46 ` [PATCH 0/6] realtek: fix management of mdb entries Vladimir Oltean
2023-03-10 18:37 ` Jan Hoffmann
2023-03-21 17:24 ` Vladimir Oltean
2023-03-21 17:25 ` Vladimir Oltean
2023-03-21 19:02 ` Andrew Lunn [this message]
2023-03-22 11:26 ` Bjørn Mork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b6223705-e34d-4f0e-8d42-021fa467d773@lunn.ch \
--to=andrew@lunn.ch \
--cc=arinc.unal@arinc9.com \
--cc=erkin.bozoglu@xeront.com \
--cc=f.fainelli@gmail.com \
--cc=jan@3e8.eu \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=openwrt-devel@lists.openwrt.org \
--cc=sander@svanheule.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox