LKML Archive on
help / color / mirror / Atom feed
From: Vladimir Oltean <>
To: DENG Qingfang <>
Cc: "Andrew Lunn" <>,
	"Vivien Didelot" <>,
	"Florian Fainelli" <>,
	"David S. Miller" <>,
	"Jakub Kicinski" <>,
	"Russell King" <>,
	"open list:NETWORKING DRIVERS" <>,
	"open list" <>,
	"Ansuel Smith" <>,
	"Jonathan McDowell" <>,
	"Michal Vokáč" <>,
	"Christian Lamparter" <>,
	"Nishka Dasgupta" <>,
	"John Crispin" <>,
	"Stefan Lippers-Hollmann" <>,
	"Hannu Nyman" <>,
	"Imran Khan" <>,
	"Frank Wunderlich" <>,
	"Nick Lowe" <>,
	"André Valentin" <>
Subject: Re: [RFC net-next 2/3] net: dsa: qca8k: enable assisted learning on CPU port
Date: Mon, 9 Aug 2021 00:10:24 +0300	[thread overview]
Message-ID: <20210808211024.pcqjfoxo5rg2umuf@skbuf> (raw)
In-Reply-To: <>

On Mon, Aug 09, 2021 at 12:05:03AM +0800, DENG Qingfang wrote:
> On Sun, Aug 08, 2021 at 01:25:55AM +0300, Vladimir Oltean wrote:
> > On Sat, Aug 07, 2021 at 08:07:25PM +0800, DENG Qingfang wrote:
> > > Enable assisted learning on CPU port to fix roaming issues.
> > 
> > 'roaming issues' implies to me it suffered from blindness to MAC
> > addresses learned on foreign interfaces, which appears to not be true
> > since your previous patch removes hardware learning on the CPU port
> > (=> hardware learning on the CPU port was supported, so there were no
> > roaming issues)
> The datasheet says learning is enabled by default, but if that's true,
> the driver won't have to enable it manually.
> Others have reported roaming issues as well:
> As I don't have the hardware to test, I don't know what the default
> value really is, so I just disable learning to make sure.

That link doesn't really say more than "roaming issues" either, so I am
still not clear on what is being fixed here exactly.

Note that I can still think of 'roaming'-related issues with VLAN-aware
bridges and foreign interfaces and hardware learning on the CPU port,
but I don't want to speculate too much and just want to hear what is the
issue that is being fixed.

> > > Although hardware learning is available, it won't work well with
> > > software bridging fallback or multiple CPU ports.
> > 
> > This part is potentially true however, but it would need proof. I am not
> > familiar enough with the qca8k driver to say for sure that it suffers
> > from the typical problem with bridging with software LAG uppers (no FDB
> > isolation for standalone ports => attempt to shortcircuit the forwarding
> > through the CPU port and go directly towards the bridged port, which
> > would result in drops), and I also can't say anything about its support
> > for multiple CPU ports.
> QCA8337 supports disabling learning and FDB lookup on a per-VLAN basis,
> so we could assign all standalone ports to a reserved VLAN (ID 0 or 4095)
> with learning and FDB lookup disabled.

And to follow along that idea, if you also change the tagger to send
all packets towards a standalone port using that reserved VLAN, then
even if hardware learning is enabled on the CPU port, it will be
inconsequential as long as IVL is used, because no FDB lookup will match
the VLAN in which those addresses were learned.

My point is, if you come with something functional to the table, present
the whole story. If more changes still need to be made until it works
with software bridging fallback, say that too. Otherwise, I think that
the general idea that "hardware learning on the CPU port won't work well
with software bridging fallback" is not strictly true, and that this
patch has a weak overall justification.

> Ansuel has a patch set for multiple CPU ports.

  reply	other threads:[~2021-08-08 21:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-07 12:07 [RFC net-next 0/3] qca8k bridge flags offload DENG Qingfang
2021-08-07 12:07 ` [RFC net-next 1/3] net: dsa: qca8k: offload bridge flags DENG Qingfang
2021-08-07 20:45   ` Vladimir Oltean
2021-08-07 12:07 ` [RFC net-next 2/3] net: dsa: qca8k: enable assisted learning on CPU port DENG Qingfang
2021-08-07 22:25   ` Vladimir Oltean
2021-08-08 16:05     ` DENG Qingfang
2021-08-08 21:10       ` Vladimir Oltean [this message]
2021-08-10 17:27       ` Andre Valentin
2021-08-10 17:53         ` Vladimir Oltean
2021-08-10 21:09           ` Andre Valentin
2021-08-10 23:33             ` Vladimir Oltean
2021-08-07 12:07 ` [RFC net-next 3/3] net: dsa: tag_qca: set offload_fwd_mark DENG Qingfang
2021-08-07 22:57   ` Vladimir Oltean
2021-08-08 16:12     ` DENG Qingfang
2021-08-08 21:14       ` Vladimir Oltean
2021-08-10  6:57 ` [RFC net-next 0/3] qca8k bridge flags offload Jonathan McDowell

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 \
    --in-reply-to=20210808211024.pcqjfoxo5rg2umuf@skbuf \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [RFC net-next 2/3] net: dsa: qca8k: enable assisted learning on CPU port' \

* 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).