netdev - 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]

Message-ID: <0842D2D2-E71C-4DEF-BBCD-2D0C0869046E@public-files.de>
Date:   Wed, 01 Mar 2023 07:38:10 +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: Re: Choose a default DSA CPU port

Am 28. Februar 2023 23:56:22 MEZ schrieb Vladimir Oltean <olteanv@...il.com>:
>On Tue, Feb 28, 2023 at 02:48:13PM +0100, Frank Wunderlich wrote:
>> I have only this datasheet from bpi for mt7531
>> 
>> https://drive.google.com/file/d/1aVdQz3rbKWjkvdga8-LQ-VFXjmHR8yf9/view
>> 
>> On page 23 the register is defined but without additional information
>> about setting multiple bits in this range. CFC IS CPU_FORWARD_CONTROL
>> register and CPU_PMAP is a 8bit part of it which have a bit for
>> selecting each port as cpu-port (0-7). I found no information about
>> packets sent over both cpu-ports, round-robin or something else.
>> 
>> For mt7530 i have no such document.
>
>I did have the document you shared and did read that description.
>I was asking for the results of some experiments because the description
>isn't clear, and characterizing the impact it has seems like a more
>practical way to find out.
>
>> The way i got from mtk some time ago was using a vlan_aware bridge for
>> selecting a "cpu-port" for a specific user-port. At this point port5
>> was no cpu-port and traffic is directly routed to this port bypassing
>> dsa and the cpu-port define in driver...afaik this way port5 was
>> handled as userport too.
>
>Sorry, I understood nothing from this. Can you rephrase?

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.

regards Frank