From: Tobias Waldekranz <tobias@waldekranz.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>, 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 12:05:19 +0100 [thread overview]
Message-ID: <87tutyu6xc.fsf@waldekranz.com> (raw)
In-Reply-To: <20201109100300.dgwce4nvddhgvzti@skbuf>
On Mon, Nov 09, 2020 at 12:03, Vladimir Oltean <olteanv@gmail.com> wrote:
> On Mon, Nov 09, 2020 at 09:09:37AM +0100, Tobias Waldekranz wrote:
>> one. But now you have also increased the background load of an already
>> choked resource, the MDIO bus.
>
> In practice, DSA switches are already very demanding of their management
> interface throughput, for PTP and things like that. I do expect that if
> you spent any significant amount of time with DSA, you already know the
> ins and outs of your MDIO/SPI/I2C controller and it would already be
> optimized for efficiency. But ok, we can add this to the list of cons.
You are arguing for my position though, no? Yes it is demanding; that is
why we must allocate it carefully.
> So there you have it, it's not that bad. More work needs to be done, but
> IMO it's still workable.
If you bypass learning on all frames sent from the CPU (as today), yes I
agree that you should be able to solve it with static entries. But I
think that you will have lots of weird problems with initial packet loss
as the FDB updates are not synchronous with the packet flow. I.e. the
bridge will tell DSA to update the entry, but the update in HW will
occur some time later when the workqueue actually performs the
operation.
> But now maybe it makes more sense to treat the switches that perform
> hardware SA learning on the CPU port separately, after I've digested
> this a bit.
Yes, please. Because it will be impossible to add tx forward offloading
otherwise.
next prev parent reply other threads:[~2020-11-09 11:05 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
2020-11-09 10:03 ` Vladimir Oltean
2020-11-09 11:05 ` Tobias Waldekranz [this message]
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=87tutyu6xc.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).