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: <trinity-6ad483d2-5c50-4f38-b386-f4941c85c1fd-1677413524438@3c-app-gmx-bs15>
Date:   Sun, 26 Feb 2023 13:12:04 +0100
From:   Frank Wunderlich <frank-w@...lic-files.de>
To:     Arınç ÜNAL <arinc.unal@...nc9.com>,
        Felix Fietkau <nbd@....name>
Cc:     Vladimir Oltean <olteanv@...il.com>,
        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:  Re: Choose a default DSA CPU port

Hi,
> Gesendet: Samstag, 25. Februar 2023 um 20:56 Uhr
> Von: "Arınç ÜNAL" <arinc.unal@...nc9.com>

> On 25.02.2023 19:11, Arınç ÜNAL wrote:
> > On 25.02.2023 16:50, Frank Wunderlich wrote:

> >> f63959c7eec3151c30a2ee0d351827b62e742dcb is the first bad commit
> > 
> > Thanks a lot for finding this. I can confirm reverting this fixes the 
> > low throughput on my Bananapi BPI-R2 as well.

> Just tested on an MT7621 Unielec U7621-06 board. MT7621 is not affected.

do you have full 1G (940 Mbit/s) on mt7621 device in 6.1??

if you look at the commit you see a special handling for mt7621

if (IS_ENABLED(CONFIG_SOC_MT7621)) {
...
}else{
//all others go there including mt7623, out (t)rgmii should be here (internally SPEED_100 afair, but higher clock for trgmii):
               case SPEED_1000:
                       val |= MTK_QTX_SCH_MAX_RATE_EN |
                              FIELD_PREP(MTK_QTX_SCH_MAX_RATE_MAN, 10) |
                              FIELD_PREP(MTK_QTX_SCH_MAX_RATE_EXP, 5) |
                              FIELD_PREP(MTK_QTX_SCH_MAX_RATE_WEIGHT, 10);
                       break;
}

but i do not understand the full code as it looks like it changes the full packet-handling ;)

imho reverting is good for test, but dropping the full change is not the right way...we should wait for felix here

but back to topic...we have a patch from vladuimir which allows setting the preferred cpu-port...how do we handle mt7531 here correctly (which still sets port5 if defined and then break)?

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/drivers/net/dsa/mt7530.c#n2383

	/* BPDU to CPU port */
	dsa_switch_for_each_cpu_port(cpu_dp, ds) {
		mt7530_rmw(priv, MT7531_CFC, MT7531_CPU_PMAP_MASK,
			   BIT(cpu_dp->index));
		break; //<<< should we drop this break only to set all "cpu-bits"? what happens then (flooding both ports with packets?)
	}

as dsa only handles only 1 cpu-port we want the real cpu-port (preferred | first). is this bit set also if the master is changed with your follow-up patch?

regards Frank

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ