Re: [PATCH net-next] net: mscc: ocelot: Workaround to allow traffic to CPU in standalone mode

On 18.02.2020 15:01, Andrew Lunn wrote:

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

On Tue, Feb 18, 2020 at 02:29:15PM +0200, Vladimir Oltean wrote:

quoted

Hi Allan,

On Tue, 18 Feb 2020 at 13:32, Allan W. Nielsen
[off-list ref] wrote:

quoted

On 17.02.2020 17:00, Vladimir Oltean wrote:

quoted

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

From: Vladimir Oltean <vladimir.oltean@nxp.com>

The Ocelot switches have what is, in my opinion, a design flaw: their
DSA header is in front of the Ethernet header, which means that they
subvert the DSA master's RX filter, which for all practical purposes,
either needs to be in promiscuous mode, or the OCELOT_TAG_PREFIX_LONG
needs to be used for extraction, which makes the switch add a fake DMAC
of ff:ff:ff:ff:ff:ff so that the DSA master accepts the frame.

The issue with this design, of course, is that the CPU will be spammed
with frames that it doesn't want to respond to, and there isn't any
hardware offload in place by default to drop them.

In the case of Ocelot, the NPI port is expected to be connected back to
back to the CPU, meaning that it should not matter what DMAC is set.

You are omitting the fact that the host Ethernet port has an RX filter
as well. By default it should drop frames that aren't broadcast or
aren't sent to a destination MAC equal to its configured MAC address.
Most DSA switches add their tag _after_ the Ethernet header. This
makes the DMAC and SMAC seen by the front-panel port of the switch be
the same as the DMAC and SMAC seen by the host port. Combined with the
fact that DSA sets up switch port MAC addresses to be inherited from
the host port, RX filtering 'just works'.

It is a little bit more complex than that, but basically yes. If the
slave interface is in promisc mode, the master interface is also made
promisc. So as soon as you add a slave to a bridge, the master it set
promisc. Also, if the slave has a different MAC address to the master,
the MAC address is added to the masters RX filter.

Good to know. I assume this will mean that in the case of Felix+NXP cpu
the master interface is in promisc mode?

If the DSA header is before the DMAC, you need promisc mode all the
time. But i don't expect the CPU port to be spammed. The switch should
only be forwarding frames to the CPU which the CPU is actually
interested in.

With Ocelot we do not see this spamming - and I still do not understand
why this is seen with Felix.

It is the same core with process the frames, and decide which frames
should be copied to the CPU. The only difference is that in Ocelot the
CPU queue is connected to a frame-DMA, while in Felix it is a MAC-to-MAC
connection.

quoted

Be there 4 net devices: swp0, swp1, swp2, swp3.
At probe time, the following doesn't work on the Felix DSA driver:
ip addr add 192.168.1.1/24 dev swp0
ping 192.168.1.2

That is expected to work.

quoted

But if I do this:
ip link add dev br0 type bridge
ip link set dev swp0 master br0
ip link set dev swp0 nomaster
ping 192.168.1.2
Then it works, because the code path from ocelot_bridge_stp_state_set
that puts the CPU port in the forwarding mask of the other ports gets
executed on the "bridge leave" action.

It probably also works because when the port is added to the bridge,
the bridge puts the port into promisc mode. That in term causes the
master to be put into promisc mode.

      Andrew

/Allan