netdev - Re: mv88e6321, dual cpu port

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230110222246.iy7m7f36iqrmiyqw@skbuf>
Date:   Wed, 11 Jan 2023 00:22:46 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Angelo Dureghello <angelo@...nel-space.org>
Cc:     Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org
Subject: Re: mv88e6321, dual cpu port

Hi Angelo,

On Tue, Jan 10, 2023 at 11:23:58AM +0100, Angelo Dureghello wrote:
> Hi Andrew,
> 
> thanks a lot for the prompt reply,
> 
> actually, seems i can use both cpu ports by
> some brctl lines:
> 
> ip link add name br0 type bridge
> ip link add name br1 type bridge
> brctl addif br0 eth0
> brctl addif br1 eth1
> 
> I verified looking the tx_packets statistics (ethtool -S)
> and both eth0 and eth1 ports are used.
> 
> Is it something that may work, eventually as a workaround ?

I am afraid that these are DSA extensions added by your kernel vendor.
I would be curious to look at the kernel code, for my amusement, if you
can share it. Generally, DSA masters (eth0, eth1 in this case) cannot be
added to a bridge, because the bridge's RX handler steals packets from
the DSA data path. So I'd also like to see what was done there.

> Also, could you help me to know the kernel version
> implementing dual cpu port properly ?

I would recommend starting with the DSA documentation on this topic:
https://www.kernel.org/doc/html/latest/networking/dsa/configuration.html#affinity-of-user-ports-to-cpu-ports
then with "git blame" on the documentation file, and "git log" to see
the surrounding commits.

For mv88e6xxx, the API for multiple CPU ports is not yet implemented.
On the other hand, there have been proposed RFC patch sets from Marek
Behun and Christian Marangi which can be picked up and used as a base
(they need to be adapted to the API that was merged).

> I cannot actually upgrade the kernel, due to cpu producer
> customizations that are not mainlined, so would try to
> downgrade the driver.

The delta between v5.4 and the kernel where support for multiple CPU
ports was added is ~600 patches to the net/dsa/ folder alone. There are
some non-trivial interdependencies with phylib, phylink, devlink, switchdev.
You might also need support for the end result, if you end up cherry picking
only what you think is useful. Hopefully that will help you reconsider.