netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tobias Waldekranz <tobias@waldekranz.com>
To: Vladimir Oltean <olteanv@gmail.com>, Andrew Lunn <andrew@lunn.ch>
Cc: DENG Qingfang <dqfext@gmail.com>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>, netdev <netdev@vger.kernel.org>,
	linux-kernel@vger.kernel.org, Marek Behun <marek.behun@nic.cz>,
	Russell King - ARM Linux admin <linux@armlinux.org.uk>
Subject: Re: [RFC PATCH net-next 3/3] net: dsa: listen for SWITCHDEV_{FDB,DEL}_ADD_TO_DEVICE on foreign bridge neighbors
Date: Mon, 09 Nov 2020 09:09:37 +0100	[thread overview]
Message-ID: <87y2jbt0hq.fsf@waldekranz.com> (raw)
In-Reply-To: <20201109003028.melbgstk4pilxksl@skbuf>

On Mon, Nov 09, 2020 at 02:30, Vladimir Oltean <olteanv@gmail.com> wrote:
> On Mon, Nov 09, 2020 at 12:59:39AM +0100, Andrew Lunn wrote:
>> We also need to make sure the static entries get removed correctly
>> when a host moves. The mv88e6xxx will not replace a static entry with
>> a dynamically learned one. It will probably rise an ATU violation
>> interrupt that frames have come in the wrong port.
>
> This is a good one. Currently every implementer of .port_fdb_add assumes
> a static entry is what we want, but that is not the case here. We want
> an entry that can expire or the switch can move it to a different port
> when there is evidence that it's wrong. Should we add more arguments to
> the API?

I don't think that would help. You would essentially be trading one
situation where station moves causes loss of traffic for another
one. But now you have also increased the background load of an already
choked resource, the MDIO bus.

At least on mv88e6xxx, your only option to allow the hardware to move
the station to another port autonomously is to add the entry as a
dynamically learnt one. However, since the switch does not perform any
SA learning on the CPU port in this world, the entry would have to be
refreshed by software, otherwise it would just age out.

Then you run in to this situation:

A and B are communicating.

       br0
  .----'|'----.
  |     |     |
swp0  swp1  wlan0
  |           |
  A           B

The switch's FDB:
A: swp0
B: cpu0 (due to this patchset)

Now B roams to an AP somewhere behind swp1 and continues to communicate
with A.

       br0
  .----'|'----.
  |     |     |
swp0  swp1  wlan0
  |     |
  A     B

The switch's FDB:
A: swp0
B: swp1

But br0 sees none of this, so at whatever interval we choose we will
refresh the FDB, moving the station back to the cpu:

A: swp0
B: cpu0

So now you have traded the issue of having to wait for the hardware to
age out its entry, to the issue of having to wait for br0 to age out its
entry. Right?

  parent reply	other threads:[~2020-11-09  8:09 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-08 13:19 [RFC PATCH net-next 0/3] Offload learnt bridge addresses to DSA Vladimir Oltean
2020-11-08 13:19 ` [RFC PATCH net-next 1/3] net: dsa: don't use switchdev_notifier_fdb_info in dsa_switchdev_event_work Vladimir Oltean
2020-11-08 23:57   ` Vladimir Oltean
2020-11-08 13:19 ` [RFC PATCH net-next 2/3] net: dsa: move switchdev event implementation under the same switch/case statement Vladimir Oltean
2020-11-11  3:44   ` Florian Fainelli
2020-11-08 13:19 ` [RFC PATCH net-next 3/3] net: dsa: listen for SWITCHDEV_{FDB,DEL}_ADD_TO_DEVICE on foreign bridge neighbors Vladimir Oltean
2020-11-08 14:09   ` DENG Qingfang
2020-11-08 17:23     ` Vladimir Oltean
2020-11-08 23:59       ` Andrew Lunn
2020-11-09  0:30         ` Vladimir Oltean
2020-11-09  1:06           ` Andrew Lunn
2020-11-09  8:09           ` Tobias Waldekranz [this message]
2020-11-09 10:03             ` Vladimir Oltean
2020-11-09 11:05               ` Tobias Waldekranz
2020-11-09 12:31                 ` Vladimir Oltean
2020-11-09 12:38                   ` Vladimir Oltean
2020-11-09 12:54                     ` Tobias Waldekranz
2020-11-13  3:48                     ` Florian Fainelli
2020-11-11 10:13       ` Alexandra Winter
2020-11-11 10:36         ` Vladimir Oltean
2020-11-11 14:14           ` Alexandra Winter
2020-11-12 13:49             ` Vladimir Oltean
2020-11-16  8:02               ` Alexandra Winter

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=87y2jbt0hq.fsf@waldekranz.com \
    --to=tobias@waldekranz.com \
    --cc=andrew@lunn.ch \
    --cc=dqfext@gmail.com \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=marek.behun@nic.cz \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=vivien.didelot@gmail.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).