From: Vladimir Oltean <olteanv@gmail.com> To: Jakub Kicinski <kuba@kernel.org>, "David S. Miller" <davem@davemloft.net> Cc: Andrew Lunn <andrew@lunn.ch>, Vivien Didelot <vivien.didelot@gmail.com>, Florian Fainelli <f.fainelli@gmail.com>, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org, Roopa Prabhu <roopa@nvidia.com>, Nikolay Aleksandrov <nikolay@nvidia.com>, Jiri Pirko <jiri@resnulli.us>, Ido Schimmel <idosch@idosch.org>, Claudiu Manoil <claudiu.manoil@nxp.com>, Alexandre Belloni <alexandre.belloni@bootlin.com>, UNGLinuxDriver@microchip.com, Vadym Kochan <vkochan@marvell.com>, Taras Chornyi <tchornyi@marvell.com>, Grygorii Strashko <grygorii.strashko@ti.com>, Ioana Ciornei <ioana.ciornei@nxp.com>, Ivan Vecera <ivecera@redhat.com>, linux-omap@vger.kernel.org Subject: Re: [PATCH v4 net-next 7/9] net: mscc: ocelot: use separate flooding PGID for broadcast Date: Fri, 12 Feb 2021 14:23:09 +0200 [thread overview] Message-ID: <20210212122309.ffv6zuhscwtvrhjk@skbuf> (raw) In-Reply-To: <20210212010531.2722925-8-olteanv@gmail.com> On Fri, Feb 12, 2021 at 03:05:29AM +0200, Vladimir Oltean wrote: > From: Vladimir Oltean <vladimir.oltean@nxp.com> > > In preparation of offloading the bridge port flags which have > independent settings for unknown multicast and for broadcast, we should > also start reserving one destination Port Group ID for the flooding of > broadcast packets, to allow configuring it individually. > > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> > Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> > --- After more testing with the ocelot-8021q tagger too, not just the default NPI-based one, I noticed that I introduced a regression. devlink-sb tells me that broadcast packets remain stuck in the ingress queues of the front-panel ports instead of being forwarded to the CPU. This is because I forgot this: -----------------------------[cut here]----------------------------- drivers/net/dsa/ocelot/felix.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/dsa/ocelot/felix.c b/drivers/net/dsa/ocelot/felix.c index 96d9d13c5ae0..2771560cef61 100644 --- a/drivers/net/dsa/ocelot/felix.c +++ b/drivers/net/dsa/ocelot/felix.c @@ -299,6 +299,7 @@ static int felix_setup_tag_8021q(struct dsa_switch *ds, int cpu) cpu_flood = ANA_PGID_PGID_PGID(BIT(ocelot->num_phys_ports)); ocelot_rmw_rix(ocelot, 0, cpu_flood, ANA_PGID_PGID, PGID_UC); ocelot_rmw_rix(ocelot, 0, cpu_flood, ANA_PGID_PGID, PGID_MC); + ocelot_rmw_rix(ocelot, 0, cpu_flood, ANA_PGID_PGID, PGID_BC); felix->dsa_8021q_ctx = kzalloc(sizeof(*felix->dsa_8021q_ctx), GFP_KERNEL); -----------------------------[cut here]----------------------------- If there is no other feedback on this series, can I send this as a follow-up fixup? Thanks.
WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Oltean <olteanv@gmail.com> To: Jakub Kicinski <kuba@kernel.org>, "David S. Miller" <davem@davemloft.net> Cc: Ivan Vecera <ivecera@redhat.com>, Andrew Lunn <andrew@lunn.ch>, Alexandre Belloni <alexandre.belloni@bootlin.com>, Florian Fainelli <f.fainelli@gmail.com>, Jiri Pirko <jiri@resnulli.us>, Vadym Kochan <vkochan@marvell.com>, netdev@vger.kernel.org, bridge@lists.linux-foundation.org, Ioana Ciornei <ioana.ciornei@nxp.com>, linux-kernel@vger.kernel.org, UNGLinuxDriver@microchip.com, Taras Chornyi <tchornyi@marvell.com>, Ido Schimmel <idosch@idosch.org>, Claudiu Manoil <claudiu.manoil@nxp.com>, Grygorii Strashko <grygorii.strashko@ti.com>, Nikolay Aleksandrov <nikolay@nvidia.com>, Roopa Prabhu <roopa@nvidia.com>, linux-omap@vger.kernel.org, Vivien Didelot <vivien.didelot@gmail.com> Subject: Re: [Bridge] [PATCH v4 net-next 7/9] net: mscc: ocelot: use separate flooding PGID for broadcast Date: Fri, 12 Feb 2021 14:23:09 +0200 [thread overview] Message-ID: <20210212122309.ffv6zuhscwtvrhjk@skbuf> (raw) In-Reply-To: <20210212010531.2722925-8-olteanv@gmail.com> On Fri, Feb 12, 2021 at 03:05:29AM +0200, Vladimir Oltean wrote: > From: Vladimir Oltean <vladimir.oltean@nxp.com> > > In preparation of offloading the bridge port flags which have > independent settings for unknown multicast and for broadcast, we should > also start reserving one destination Port Group ID for the flooding of > broadcast packets, to allow configuring it individually. > > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> > Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> > --- After more testing with the ocelot-8021q tagger too, not just the default NPI-based one, I noticed that I introduced a regression. devlink-sb tells me that broadcast packets remain stuck in the ingress queues of the front-panel ports instead of being forwarded to the CPU. This is because I forgot this: -----------------------------[cut here]----------------------------- drivers/net/dsa/ocelot/felix.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/dsa/ocelot/felix.c b/drivers/net/dsa/ocelot/felix.c index 96d9d13c5ae0..2771560cef61 100644 --- a/drivers/net/dsa/ocelot/felix.c +++ b/drivers/net/dsa/ocelot/felix.c @@ -299,6 +299,7 @@ static int felix_setup_tag_8021q(struct dsa_switch *ds, int cpu) cpu_flood = ANA_PGID_PGID_PGID(BIT(ocelot->num_phys_ports)); ocelot_rmw_rix(ocelot, 0, cpu_flood, ANA_PGID_PGID, PGID_UC); ocelot_rmw_rix(ocelot, 0, cpu_flood, ANA_PGID_PGID, PGID_MC); + ocelot_rmw_rix(ocelot, 0, cpu_flood, ANA_PGID_PGID, PGID_BC); felix->dsa_8021q_ctx = kzalloc(sizeof(*felix->dsa_8021q_ctx), GFP_KERNEL); -----------------------------[cut here]----------------------------- If there is no other feedback on this series, can I send this as a follow-up fixup? Thanks.
next prev parent reply other threads:[~2021-02-12 12:26 UTC|newest] Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-02-12 1:05 [PATCH v4 net-next 0/9] Cleanup in brport flags switchdev offload for DSA Vladimir Oltean 2021-02-12 1:05 ` [Bridge] " Vladimir Oltean 2021-02-12 1:05 ` [PATCH v4 net-next 1/9] net: switchdev: propagate extack to port attributes Vladimir Oltean 2021-02-12 1:05 ` [Bridge] " Vladimir Oltean 2021-02-12 3:20 ` Florian Fainelli 2021-02-12 3:20 ` [Bridge] " Florian Fainelli 2021-02-12 1:05 ` [PATCH v4 net-next 2/9] net: bridge: offload all port flags at once in br_setport Vladimir Oltean 2021-02-12 1:05 ` [Bridge] " Vladimir Oltean 2021-02-12 1:05 ` [PATCH v4 net-next 3/9] net: bridge: don't print in br_switchdev_set_port_flag Vladimir Oltean 2021-02-12 1:05 ` [Bridge] " Vladimir Oltean 2021-02-12 1:05 ` [PATCH v4 net-next 4/9] net: dsa: configure better brport flags when ports leave the bridge Vladimir Oltean 2021-02-12 1:05 ` [Bridge] " Vladimir Oltean 2021-02-12 1:05 ` [PATCH v4 net-next 5/9] net: switchdev: pass flags and mask to both {PRE_,}BRIDGE_FLAGS attributes Vladimir Oltean 2021-02-12 1:05 ` [Bridge] [PATCH v4 net-next 5/9] net: switchdev: pass flags and mask to both {PRE_, }BRIDGE_FLAGS attributes Vladimir Oltean 2021-02-12 1:05 ` [PATCH v4 net-next 6/9] net: dsa: act as ass passthrough for bridge port flags Vladimir Oltean 2021-02-12 1:05 ` [Bridge] " Vladimir Oltean 2021-02-12 8:36 ` Vladimir Oltean 2021-02-12 8:36 ` [Bridge] " Vladimir Oltean 2021-02-12 1:05 ` [PATCH v4 net-next 7/9] net: mscc: ocelot: use separate flooding PGID for broadcast Vladimir Oltean 2021-02-12 1:05 ` [Bridge] " Vladimir Oltean 2021-02-12 12:23 ` Vladimir Oltean [this message] 2021-02-12 12:23 ` Vladimir Oltean 2021-02-12 1:05 ` [PATCH v4 net-next 8/9] net: mscc: ocelot: offload bridge port flags to device Vladimir Oltean 2021-02-12 1:05 ` [Bridge] " Vladimir Oltean 2021-02-12 1:05 ` [PATCH v4 net-next 9/9] net: dsa: sja1105: " Vladimir Oltean 2021-02-12 1:05 ` [Bridge] " Vladimir Oltean 2021-02-12 14:17 ` [PATCH v4 net-next 0/9] Cleanup in brport flags switchdev offload for DSA Grygorii Strashko 2021-02-12 14:31 ` Vignesh Raghavendra 2021-02-12 14:31 ` [Bridge] " Vignesh Raghavendra 2021-02-12 14:40 ` Vladimir Oltean 2021-02-12 14:40 ` [Bridge] " Vladimir Oltean 2021-02-16 11:22 ` Vignesh Raghavendra 2021-02-16 11:22 ` [Bridge] " Vignesh Raghavendra
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=20210212122309.ffv6zuhscwtvrhjk@skbuf \ --to=olteanv@gmail.com \ --cc=UNGLinuxDriver@microchip.com \ --cc=alexandre.belloni@bootlin.com \ --cc=andrew@lunn.ch \ --cc=bridge@lists.linux-foundation.org \ --cc=claudiu.manoil@nxp.com \ --cc=davem@davemloft.net \ --cc=f.fainelli@gmail.com \ --cc=grygorii.strashko@ti.com \ --cc=idosch@idosch.org \ --cc=ioana.ciornei@nxp.com \ --cc=ivecera@redhat.com \ --cc=jiri@resnulli.us \ --cc=kuba@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=netdev@vger.kernel.org \ --cc=nikolay@nvidia.com \ --cc=roopa@nvidia.com \ --cc=tchornyi@marvell.com \ --cc=vivien.didelot@gmail.com \ --cc=vkochan@marvell.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.