netdev - Re: [RFT net-next] net: stmmac: Rework coalesce timer and fix multi-queue races

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 4 Sep 2018 11:00:45 +0100
From:   Jose Abreu <Jose.Abreu@...opsys.com>
To:     Jerome Brunet <jbrunet@...libre.com>,
        Jose Abreu <Jose.Abreu@...opsys.com>, <netdev@...r.kernel.org>
CC:     Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        "David S. Miller" <davem@...emloft.net>,
        Joao Pinto <Joao.Pinto@...opsys.com>,
        Giuseppe Cavallaro <peppe.cavallaro@...com>,
        Alexandre Torgue <alexandre.torgue@...com>
Subject: Re: [RFT net-next] net: stmmac: Rework coalesce timer and fix
 multi-queue races



On 04-09-2018 10:16, Jerome Brunet wrote:
> On Mon, 2018-09-03 at 16:47 +0100, Jose Abreu wrote:
>> On 03-09-2018 16:38, Jerome Brunet wrote:
>>> On Mon, 2018-09-03 at 16:22 +0100, Jose Abreu wrote:
>>>> On 03-09-2018 15:10, Jerome Brunet wrote:
>>>>> On Mon, 2018-09-03 at 12:47 +0100, Jose Abreu wrote:
>>>>>> On 03-09-2018 11:16, Jerome Brunet wrote:
>>>>>>> No notable change. Rx is fine but Tx:
>>>>>>> [  5]   3.00-4.00   sec  3.55 MBytes  29.8 Mbits/sec   51   12.7 KBytes
>>>>>>>
>>>>>>> I suppose the problem as something to do with the retries. When doing Tx test
>>>>>>> alone, we don't have such a things a throughput where we expect it to be.
>>>>>> Yeah, I just remembered you are not using GMAC4 so it wouldn't
>>>>>> make a difference. Is your version 3.710? If so please try adding
>>>>>> the following compatible to your DT bindings "snps,dwmac-3.710".
>>>>> According to the documentation, it is a 3.70a but I learn (the hard way) not to
>>>>> trust the documentation too much. Is there anyway to make sure which version we
>>>>> have. Like a register to read ?
>>>> It should be dumped at probe by a string like this one:
>>>>
>>>> "User ID: 0xXY, Synopsys ID: 0xXZ"
>>> User ID: 0x11, Synopsys ID: 0x37 ? What to does it map to ?
>> Its 3.7. As for the User ID this can be changed by final HW team
>> so I can't confirm what it means.
>>
> Is there anyway to know if it is a 3.70a or 3.71 ?

If the user ID wasn't changed from default then its 3.71.

>
>>>>> Out of curiosity, I changed the compatible to "snps,dwmac-3.710" anyway. For
>>>>> some reason, the MDIO bus failed to register with this. Since it is not the
>>>>> documented version, I did not check why.
>>>> No you can't change. You need to add it. So it should stay like this:
>>>>
>>>> compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac",
>>>> "snps,dwmac-3.710";
>>> Adding "snps,dwmac-3.710" does not change anything for me.
>>> Having both Tx and Rx at the same time still wreck Tx throughput unfortunately 
>> Okay, so you said that there are lots of retries: can you disable
>> COE at all ? (it should be something like: ethtool -K eth0 rx off
>> tx off).
> Done but no change.

Ok. Are you able to analyze the sent / received packets using
pcap so that we can understand why there are lots of retries ?

Thanks and Best Regards,
Jose Miguel Abreu

>
>> Thanks and Best Regards,
>> Jose Miguel Abreu
>>
>>>> Thanks and Best Regards,
>>>> Jose Miguel Abreu
>>>>
>>>>>>> By the way, your mailer (and its auto 80 column rule I suppose) made the patch
>>>>>>> below a bit harder to apply
>>>>>> Sorry. Next time I will send as attachment.
>>>>> No worries
>>>>>
>>>>>> Thanks and Best Regards,
>>>>>> Jose Miguel Abreu
>>
>