netdev - Re: [PATCH 1/2] stmmac: introduce flag to dynamically disable TX offload for rockchip devices

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:   Tue, 2 Apr 2019 23:08:11 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     Jose Abreu <jose.abreu@...opsys.com>,
        Philipp Tomsich <philipp.tomsich@...obroma-systems.com>,
        Heiko Stübner <heiko@...ech.de>,
        Christoph Müllner 
        <christoph.muellner@...obroma-systems.com>
Cc:     "Leonidas P. Papadakos" <papadakospan@...il.com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre Torgue <alexandre.torgue@...com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Klaus Goger <klaus.goger@...obroma-systems.com>
Subject: Re: [PATCH 1/2] stmmac: introduce flag to dynamically disable TX
 offload for rockchip devices

On 2019-04-02 12:53 pm, Jose Abreu wrote:
> From: Robin Murphy <robin.murphy@....com>
> Date: Tue, Apr 02, 2019 at 12:49:36
> 
>> On 02/04/2019 08:59, Jose Abreu wrote:
>>> From: Philipp Tomsich <philipp.tomsich@...obroma-systems.com>
>>> Date: Mon, Apr 01, 2019 at 20:12:21
>>>
>>>> + Christoph.
>>>>
>>>>> On 01.04.2019, at 21:06, Heiko Stübner <heiko@...ech.de> wrote:
>>>>>
>>>>> Am Montag, 1. April 2019, 20:54:45 CEST schrieb Robin Murphy:
>>>>>> On 01/04/2019 19:18, Leonidas P. Papadakos wrote:
>>>>>>> From: =?UTF-8?q?Kamil=20Trzci=C5=84ski?= <ayufan@...fan.eu>
>>>>>>>
>>>>>>> Some rockchip boards exhibit an issue where tx checksumming does not
>> work
>>>> with
>>>>>>> packets larger than 1498.
>>>>>>
>>>>>> Is it really a board-level problem? I'm no networking expert, but the
>>>>>> nature of the workaround suggests this is more likely to be some
>>>>>> inherent limitation of the IP block in the SoC, rather than something to
>>>>>> do with how the external pins get wired up. Does anyone have an RK3328
>>>>>> or RK3399 board that provably *does* checksum large packets correctly?
>>>>>
>>>>> I don't have that many rk3399-boards with actual ethernet and even only
>>>>> the rock64 from rk3328-land, but at least my rk3399-firefly also seems
>>>>> affected by this.
>>>>>
>>>>> But so far the rk3399-puma board from Theobroma did not show that
>> ethernet
>>>>> issue for me, so I've added two Theobroma people who may or may not tell
>>>>> if they've also seen that issue.
>>>>>
>>>>>>
>>>>>>> This is bad for network stability.
>>>>>>>
>>>>>>> The previous approach was using force_thresh_dma_mode in the board dts,
>>>> which
>>>>>>> does more than we need.
>>>>>>
>>>>>> If indeed it is a SoC-level thing (or at least we want to treat it as
>>>>>> such), then couldn't we just hang it off the existing SoC-specific
>>>>>> compatibles in dwmac-rk.c and avoid the need for a new DT property at
>>>>>> all? After all, that's precisely why SoC-specific compatibles are a
>>>>>> thing in the first place.
>>>>>>
>>>
>>> This can happen when FIFO size + PBL settings are not big enough for COE.
>>>
>>> Can you please share the above settings ?
>>
>> Can the FIFO size be discovered by dumping registers, or does someone
>> from Rockchip need to look up the IP configuration details?
>>
>> FWIW, taking a look at the RK3399 TRM, this (p788) jumps out:
>>
>> "PBL
>> ...
>> For TxFIFO, valid PBL range in full duplex mode and duplex mode is
>> 128 or less.
>> For RxFIFO, valid PBL range in full duplex mode is all."
>>
>>
>> Does that suggest that it's worth fiddling with the "snps,txpbl" value
>> in DT?
> 
> Yes, please try with PBL = 0x1 and no-pbl-x8. Performance will be lower
> but at least we will know if that’s the cause.

OK, this looks promising - I've never encountered the problem 
'naturally' myself, but I managed to contrive a test setup with my 
RK3399 board wired directly to a laptop running an iperf3 server. As 
standard with an MTU of 1500, I get ~940Mbps as expected; with MTU 
bumped up to 1550 at both ends, the client grinds to a halt after ~100KB 
sent with a dozen or so retries, and the server reports 0 bytes 
received; with "snps,no-pbl-x8" present and the MTU still at 1550, it's 
back to ~940Mbps with 0 retries again.

I'll experiment further with txpbl, and my other boards, as and when I 
have time, but at this point I'm already pretty much convinced you're 
right about that Tx FIFO.

Cheers,
Robin.