netdev - Aw: Re: Choose a default DSA 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]

Date:   Mon, 6 Mar 2023 19:20:25 +0100
From:   Frank Wunderlich <frank-w@...lic-files.de>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Arınç ÜNAL <arinc.unal@...nc9.com>,
        Felix Fietkau <nbd@....name>, netdev <netdev@...r.kernel.org>,
        erkin.bozoglu@...ont.com, Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        John Crispin <john@...ozen.org>,
        Mark Lee <Mark-MC.Lee@...iatek.com>,
        Lorenzo Bianconi <lorenzo@...nel.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Landen Chao <Landen.Chao@...iatek.com>,
        Sean Wang <sean.wang@...iatek.com>,
        DENG Qingfang <dqfext@...il.com>
Subject: Aw: Re: Choose a default DSA CPU port

Hi,

sorry for the delay, but have not yet found time to test :(

> Gesendet: Mittwoch, 01. März 2023 um 13:37 Uhr
> Von: "Vladimir Oltean" <olteanv@...il.com>
> Betreff: Re: Choose a default DSA CPU port
>
> On Wed, Mar 01, 2023 at 07:38:10AM +0100, Frank Wunderlich wrote:
> > It was a userspace way to use the second ethernet lane p5-mac1 without
> > defining p5 as cpu-port (and so avoiding this cpu-port handling).
> > I know it is completely different,but maybe using multiple cpu-ports
> > require some vlan assignment inside the switch to not always flood
> > both cpu-ports with same packets. So p5 could only accept tagged
> > packets which has to been tagged by userport.
> > 
> > How can i check if same packets processed by linux  on gmacs (in case
> > i drop the break for testing)? Looking if rx increases the same way
> > for both macs looks not like a reliable test.
> 
> I'd say that using a protocol with sequence numbers would be a good way
> to do that. Most obvious would be ping (ICMP), but if the code comment
> is right and MT7531_CFC[MT7531_CPU_PMAP_MASK] only affects link-local
> multicast packet trapping (the 01:80:c2:00:00:xx MAC DA range), then
> this won't do anything, because ping is unicast.

is it possible to map this function only to mt7530, not mt7531?

as one way i would add a check for the chip

if (priv->id != ID_MT7530) { return NULL; }
//existing content for mt7531

where did you find the comment about multicast?

https://elixir.bootlin.com/linux/v6.3-rc1/source/drivers/net/dsa/mt7530.c has
"multicast" only in the packet-counters (mib_desc)

> The next most obvious thing would be L2 PTP (ptp4l -2), but since mt7530
> doesn't support hw timestamping, you'd need to try software timestamping
> instead ("ptp4l -i swpX -2 -P -S -m", plus the equivalent command on a
> link partner).

have not done anything with l2 p2p yet, and no server running...i'm not sure
i can check this the right way.

> When testing, make sure that both CPU ports are active and their DSA
> masters are up! Otherwise, the switch may send duplicate link-local
> packets to both CPU ports, but DSA would only process one of them,
> leading us to believe that there isn't any duplication.

> Putting a tcpdump -i eth0 -w eth0.pcap and a tcpdump -i eth1 -w eth1.pcap
> in parallel would also be a good way to double-check.

regards Frank