linux-kernel - Re: [PATCH net 1/1] net: stmmac: Resolve poor line rate after switching from TSO off to TSO on

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] [day] [month] [year] [list]

Message-ID: <20220715125148.GA21603@linux.intel.com>
Date:   Fri, 15 Jul 2022 20:51:48 +0800
From:   Wong Vee Khee <vee.khee.wong@...ux.intel.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     "David S . Miller" <davem@...emloft.net>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Giuseppe Cavallaro <peppe.cavallaro@...com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Jose Abreu <joabreu@...opsys.com>, netdev@...r.kernel.org,
        linux-stm32@...md-mailman.stormreply.com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        pei.lee.ling@...el.com
Subject: Re: [PATCH net 1/1] net: stmmac: Resolve poor line rate after
 switching from TSO off to TSO on

On Wed, Mar 02, 2022 at 10:32:48PM -0800, Jakub Kicinski wrote:
> On Mon, 28 Feb 2022 19:15:58 +0800 Wong Vee Khee wrote:
> > From: Ling Pei Lee <pei.lee.ling@...el.com>
> > 
> > Sequential execution of these steps:
> > i) TSO ON – iperf3 execution,
> > ii) TSO OFF – iperf3 execution,
> > iii) TSO ON – iperf3 execution, it leads to iperf3 0 bytes transfer.
> 
> IMHO the iperf output can be dropped from the commit message, 
> it doesn't add much beyond this description.
>

Noted. Will drop those on next revision of pull request.
 
> > Clear mss in TDES and call stmmac_enable_tso() to indicate
> > a new TSO transmission when it is enabled from TSO off using
> > ethtool command
> 
> How does the TSO get disabled I don't see any ...enable_tso(, 0, )
> calls in the driver? And why call enable in fix_features rather 
> than set_features?

It is disable when 'priv->tso = 0' in this same function.
The reason I put this in fix_features rather than set_features is
because the commit f748be531d70("stmmac: support new GMAC4") has
already introduced the following codes in fix_features:-

+	/* Disable tso if asked by ethtool */
+	if ((priv->plat->tso_en) && (priv->dma_cap.tsoen)) {
+		if (features & NETIF_F_TSO)
+			priv->tso = true;
+		else
+			priv->tso = false;
+	}

BR,
 Vee Khee