From: Vladimir Oltean <olteanv@gmail.com>
To: "Allan W. Nielsen" <allan.nielsen@microchip.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Horatiu Vultur <horatiu.vultur@microchip.com>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Florian Fainelli <f.fainelli@gmail.com>,
Vivien Didelot <vivien.didelot@gmail.com>,
Joergen Andreasen <joergen.andreasen@microchip.com>,
Claudiu Manoil <claudiu.manoil@nxp.com>,
netdev <netdev@vger.kernel.org>,
Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
Subject: Re: [PATCH net-next] net: mscc: ocelot: Workaround to allow traffic to CPU in standalone mode
Date: Wed, 19 Feb 2020 16:05:08 +0200 [thread overview]
Message-ID: <CA+h21hp5NQNJJ5agMPAZ+edaZ+ouSjTJ8DypYR5Htx3ZT5iSYA@mail.gmail.com> (raw)
In-Reply-To: <20200219101739.65ucq6a4dmlfgfki@lx-anielsen.microsemi.net>
On Wed, 19 Feb 2020 at 12:17, Allan W. Nielsen
<allan.nielsen@microchip.com> wrote:
>
> With Ocelot we do not see this spamming - and I still do not understand
> why this is seen with Felix.
>
I should have watched my words.
When doing what all the other DSA switches do, which is enabling a
bulk forwarding path between the front-panel ports and the CPU, the
Ocelot switch core is more susceptible to doing more software
processing work than other devices in its class, for the same end
effect of dropping packets that the CPU is not interested in (say an
unknown unicast MAC that is not present in the switch FDB nor in the
DSA master's RX filter). In such a scenario, any other DSA system
would have the host port drop these packets in hardware, by virtue of
the unknown unicast MAC not being being present RX filter. With
Ocelot, this mechanism that prevents software work being done for
dropping is subverted. So to avoid this design limitation, the Ocelot
core does not enable a bulk forwarding path between the front-panel
ports and the CPU.
Hope this is clearer.
-Vladimir
next prev parent reply other threads:[~2020-02-19 14:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-17 15:00 [PATCH net-next] net: mscc: ocelot: Workaround to allow traffic to CPU in standalone mode Vladimir Oltean
2020-02-18 11:31 ` Allan W. Nielsen
2020-02-18 12:29 ` Vladimir Oltean
2020-02-18 13:48 ` Allan W. Nielsen
2020-02-18 14:02 ` Vladimir Oltean
2020-02-19 10:11 ` Allan W. Nielsen
2020-02-19 13:55 ` Vladimir Oltean
2020-02-19 14:18 ` Vladimir Oltean
2020-02-18 14:01 ` Andrew Lunn
2020-02-18 14:05 ` Vladimir Oltean
2020-02-19 10:17 ` Allan W. Nielsen
2020-02-19 14:05 ` Vladimir Oltean [this message]
2020-02-20 13:23 ` Allan W. Nielsen
2020-02-20 15:56 ` Vladimir Oltean
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=CA+h21hp5NQNJJ5agMPAZ+edaZ+ouSjTJ8DypYR5Htx3ZT5iSYA@mail.gmail.com \
--to=olteanv@gmail.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=allan.nielsen@microchip.com \
--cc=andrew@lunn.ch \
--cc=claudiu.manoil@nxp.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=horatiu.vultur@microchip.com \
--cc=joergen.andreasen@microchip.com \
--cc=netdev@vger.kernel.org \
--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 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.