From: Andrew Lunn <andrew@lunn.ch>
To: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Cc: netdev <netdev@vger.kernel.org>,
jiri@resnulli.us, nikolay@cumulusnetworks.com,
Florian Fainelli <f.fainelli@gmail.com>
Subject: Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic
Date: Wed, 6 Sep 2017 19:01:20 +0200 [thread overview]
Message-ID: <20170906170120.GF15315@lunn.ch> (raw)
In-Reply-To: <874lsfg87t.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
On Wed, Sep 06, 2017 at 11:25:26AM -0400, Vivien Didelot wrote:
> Hi Andrew, Nikolay,
>
> Andrew Lunn <andrew@lunn.ch> writes:
>
> > Then starts the work passing down to the hardware that the host has
> > joined/left a group. The existing switchdev mdb object cannot be used,
> > since the semantics are different. The existing
> > SWITCHDEV_OBJ_ID_PORT_MDB is used to indicate a specific multicast
> > group should be forwarded out that port of the switch. However here we
> > require the exact opposite. We want multicast frames for the group
> > received on the port to the forwarded to the host. Hence add a new
> > object SWITCHDEV_OBJ_ID_HOST_MDB, a multicast database entry to
> > forward to the host. This new object is then propagated through the
> > DSA layers. No DSA driver changes should be needed, this should just
> > work...
>
> I'm not sure if you already explained that, if so, sorry in advance.
>
> I don't understand why SWITCHDEV_OBJ_ID_PORT_MDB cannot be used. Isn't
> setting the obj->orig_dev to the bridge device itself enough to
> distinguish br0 from a switch port?
Hi Vivien
I did consider this. But conceptually, it seems wrong.
SWITCHDEV_OBJ_ID_PORT_MDB has always been about egress. I don't like
adding a special case for ingress. Adding a new switchdev object
avoids this special case.
> static int dsa_slave_port_obj_add(struct net_device *dev,
> const struct switchdev_obj *obj,
> struct switchdev_trans *trans)
> {
> struct dsa_slave_priv *p = netdev_priv(dev);
> struct dsa_port *port = p->dp;
>
> /* Is the target port the bridge device itself? */
> if (obj->orig_dev == port->br)
> port = port->cpu_dp;
>
> return dsa_port_mdb_add(port, obj, trans);
> }
>
> The main problem is that we will soon want support for multiple CPU
> ports.
We keep saying that, but it never actually happens. We should solve
multiple CPU problems when we actually add support for multiple CPUs.
Probably at that point, we need to push SWITCHDEV_OBJ_ID_PORT_HOST_MDB
right down to a port, so that port can setup what needs setting up so
its frames goes to its CPU port.
> So adding the MDB entry to all CPU ports as you did in a patch 5/8 in
> dsa_switch_host_mdb_*() is not correct because you can have CPU port
> sw0p0 being a member of br0 and CPU port sw0p10 being a member of br1.
Be careful, you are making assumptions about mapping cpu ports to
bridges. That is not been defined yet.
Andrew
next prev parent reply other threads:[~2017-09-06 17:01 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-05 23:35 [PATCH v2 rfc 0/8] IGMP snooping for local traffic Andrew Lunn
2017-09-05 23:35 ` [PATCH v2 rfc 1/8] net: bridge: Rename mglist to host_joined Andrew Lunn
2017-09-05 23:35 ` [PATCH v2 rfc 2/8] net: bridge: Send notification when host join/leaves a group Andrew Lunn
2017-09-05 23:35 ` [PATCH v2 rfc 3/8] net: bridge: Add/del switchdev object on host join/leave Andrew Lunn
2017-09-05 23:35 ` [PATCH v2 rfc 4/8] net: dsa: slave: Handle switchdev host mdb add/del Andrew Lunn
2017-09-06 15:37 ` Vivien Didelot
2017-09-05 23:35 ` [PATCH v2 rfc 5/8] net: dsa: switch: handle host mdb add/remove Andrew Lunn
2017-09-05 23:35 ` [PATCH v2 rfc 6/8] net: dsa: switch: Don't add CPU port to an mdb by default Andrew Lunn
2017-09-05 23:35 ` [PATCH v2 rfc 7/8] net: dsa: set offload_fwd_mark on received packets Andrew Lunn
2017-09-05 23:35 ` [PATCH v2 rfc 8/8] net: dsa: Fix SWITCHDEV_ATTR_ID_PORT_PARENT_ID Andrew Lunn
2017-09-06 14:46 ` Vivien Didelot
2017-09-06 15:08 ` Andrew Lunn
2017-09-06 16:09 ` Florian Fainelli
2017-09-06 16:29 ` Andrew Lunn
2017-09-06 0:11 ` [PATCH v2 rfc 0/8] IGMP snooping for local traffic Stephen Hemminger
2017-09-06 9:52 ` Nikolay Aleksandrov
2017-09-06 0:47 ` Andrew Lunn
2017-09-06 13:56 ` Vivien Didelot
2017-09-06 14:16 ` Andrew Lunn
2017-09-06 14:27 ` John Crispin
2017-09-06 14:46 ` Matthias May
2017-09-06 15:16 ` Andrew Lunn
2017-09-06 15:27 ` Stephen Hemminger
2017-09-06 15:49 ` Woojung.Huh
2017-09-06 15:54 ` Roopa Prabhu
2017-09-06 16:06 ` Florian Fainelli
2017-09-06 16:42 ` Andrew Lunn
2017-09-06 19:54 ` Florian Fainelli
2017-09-06 23:44 ` Woojung.Huh
2017-09-07 0:43 ` Andrew Lunn
2017-09-07 0:47 ` Andrew Lunn
2017-09-06 14:29 ` Vivien Didelot
2017-09-06 15:25 ` Vivien Didelot
2017-09-06 17:01 ` Andrew Lunn [this message]
2017-09-06 18:29 ` Vivien Didelot
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=20170906170120.GF15315@lunn.ch \
--to=andrew@lunn.ch \
--cc=f.fainelli@gmail.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--cc=vivien.didelot@savoirfairelinux.com \
/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;
as well as URLs for NNTP newsgroup(s).