archive mirror
 help / color / mirror / Atom feed
From: Tobias Waldekranz <>
To: Andrew Lunn <>,
	Rasmus Villemoes <>
Cc: Network Development <>,
	Vivien Didelot <>,
	Horatiu Vultur <>,
	Vladimir Oltean <>
Subject: Re: commit 4c7ea3c0791e (net: dsa: mv88e6xxx: disable SA learning for DSA and CPU ports)
Date: Mon, 18 Jan 2021 19:30:49 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Jan 18, 2021 at 18:50, Andrew Lunn <> wrote:
>> I suppose the real solution is having userspace do some "bridge mdb add"
>> yoga, but since no code currently uses
>> MV88E6XXX_G1_ATU_DATA_STATE_MC_STATIC_DA_MGMT, I don't think there's any
>> way to actually achieve this. And I have no idea how to represent the
>> requirement that "frames with this multicast DA are only to be directed
>> at the CPU" in a hardware-agnostic way.
> The switchdev interface for this exists, because there can be
> multicast listeners on the bridge. When they join a group, they ask
> the switch to put in a HOST MDB, which should cause the traffic for

That is not quite the same thing as "management" though. Adding the
group to the host MDB will not allow it to pass through blocked (in the
STP sense) ports for example. With a management entry, the switch will
trap the packet with a TO_CPU tag, which means no ingress policy can get
in the way of it reaching the CPU.

> the group to be sent to the host. What you don't have is the
> exclusivity. If there is an IGMP report for the DA received on another
> port, IGMP snooping will add an MDB entry to forward traffic out that
> port.

Exclusivity should not be an issue as these protocols use groups outside
of the ranges allocated for IGMP/MLD.

I see a few ways forward:

1. Extending the MRP-support in the bridge to support other protocols
   (e.g. ERP). If DSA gets a callback saying that a ring has been setup
   with a certain role, we know which groups to add. Good for defined
   protocols - does not help anyone who needs to be able to configure
   custom groups.

2. Adding yet another flag to MDB entries to mark them as "trap"
   entries. I do not see thing going anywhere since the big fish have
   already solved this with...

3. ... TC, through the "trap" action. We could detect filters which only
   match on DA, with the action "trap"; and convert those to MGMT
   entries in the ATU. I think this could be the way forward for user
   defined entries.

4. Devlink trap configuration. Maybe? I have not managed to wrap my head
   around this yet.

  reply	other threads:[~2021-01-18 18:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-14 13:49 Rasmus Villemoes
2021-01-16  1:42 ` Tobias Waldekranz
2021-01-18 15:41   ` Rasmus Villemoes
2021-01-18 17:50     ` Andrew Lunn
2021-01-18 18:30       ` Tobias Waldekranz [this message]
2021-01-18 19:01         ` Andrew Lunn
2021-01-18 19:10           ` Tobias Waldekranz
2021-01-18 21:19   ` Vladimir Oltean
2021-01-18 22:07     ` Rasmus Villemoes
2021-01-18 23:08       ` Tobias Waldekranz
2021-01-19  9:15       ` Horatiu Vultur

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \
    --subject='Re: commit 4c7ea3c0791e (net: dsa: mv88e6xxx: disable SA learning for DSA and CPU ports)' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).