netdev - Re: [PATCH V3 00/18] net: ks8851: Unify KS8851 SPI and MLL drivers

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:   Fri, 10 Apr 2020 20:10:48 +0200
From:   Marek Vasut <marex@...x.de>
To:     Lukas Wunner <lukas@...ner.de>
Cc:     netdev@...r.kernel.org, "David S . Miller" <davem@...emloft.net>,
        Petr Stetiar <ynezz@...e.cz>,
        YueHaibing <yuehaibing@...wei.com>
Subject: Re: [PATCH V3 00/18] net: ks8851: Unify KS8851 SPI and MLL drivers

On 4/10/20 1:01 PM, Lukas Wunner wrote:
> On Wed, Apr 08, 2020 at 09:49:14PM +0200, Marek Vasut wrote:
>> On 4/6/20 1:20 PM, Marek Vasut wrote:
>>> On 4/6/20 5:16 AM, Lukas Wunner wrote:
>>>> I'll be back at the office this week and will conduct performance
>>>> measurements with this version.
> 
> Latency without this series (ping -A -c 100000):
> 
> 100000 packets transmitted, 100000 received, 0% packet loss, time 205ms
> rtt min/avg/max/mdev = 0.790/1.695/2.624/0.046 ms, ipg/ewma 2.000/1.693 ms
>                              ^^^^^
> Latency with this series:
> 
> 100000 packets transmitted, 100000 received, 0% packet loss, time 220ms
> rtt min/avg/max/mdev = 0.880/1.717/2.428/0.059 ms, ipg/ewma 2.000/1.710 ms
> 
> Latency with this series + my patch to inline accessors:
> 
> 100000 packets transmitted, 100000 received, 0% packet loss, time 219ms
> rtt min/avg/max/mdev = 0.874/1.716/3.296/0.058 ms, ipg/ewma 2.000/1.719 ms
> 
> 
> RX throughput without this series (iperf3 -f k -i 0 -c):
> 
> [  5]   0.00-10.00  sec  19.0 MBytes  15958 Kbits/sec                  receiver
> 
> RX throughput with this series:
> 
> [  5]   0.00-10.00  sec  18.4 MBytes  15452 Kbits/sec                  receiver
> 
> RX throughput with this series + my patch to inline accessors:
> 
> [  5]   0.00-10.00  sec  18.5 MBytes  15506 Kbits/sec                  receiver
> 
> 
> TX throughput without this series (iperf3 -R -f k -i 0 -c):
> 
> [  5]   0.00-10.00  sec  18.6 MBytes  15604 Kbits/sec                  receiver
> 
> TX throughput with this series:
> 
> [  5]   0.00-10.00  sec  18.3 MBytes  15314 Kbits/sec                  receiver
> 
> TX throughput with this series + my patch to inline accessors:
> 
> [  5]   0.00-10.00  sec  18.3 MBytes  15349 Kbits/sec                  receiver
> 
> 
> The commands were invoked from a machine with a Broadcom tg3
> Gigabit Ethernet controller.

It would be helpful if we could at least run the same test, so the
results are comparable.

> Conclusion:  The series does incur a measurable performance penalty
> which should be fixed before it gets merged.  Inlining the accessors
> only yields a very small improvement.

OK, so we finally agree on this, thanks.

> I'm wondering where the
> performance penalty is originating from:  Perhaps because of the
> 16-bit read of RXFC in ks8851_rx_pkts()?

Can you patch that part away to see whether that's the case ?

>> So I got the KS8851SNL development kit to test the SPI option. The
>> current driver in linux-next gives me SPI transfer timeouts at 1 MHz (I
>> also tried 6 MHz, 10 MHz, same problem, I also checked the signal
>> quality which is OK) both on iMX6Q and on STM32MP1 with ~2 cm long
>> wiring between the SoM and the KS8851SNL devkit, so that's where my
>> testing ends, sadly. Unless you have some idea what the problem might be ?
> 
> Check the signal quality with an oscilloscope.
> Crank up drive strength of the SPI pins if supported by the pin controller.

I already tried both, got nothing useful.

> Check if the driver for the SPI controller is buggy or somehow limits the
> speed.

I used two different drivers -- the iMX SPI and the STM32 SPI -- I would
say that if both show the same behavior, it's unlikely to be the driver.

> We use the KSZ8851SNL both with STM32-based products (at 20 MHz SPI clock,
> but without an operating system) and with Raspberry Pi based products
> (at up to 25 MHz SPI clock, with Linux).  It is only the latter that
> I'm really familiar with.  We've invested considerable resources to
> fix bugs and speed up the Raspberry Pi's SPI driver as much as possible.
> By now it works pretty well with the ks8851.
> 
> A Raspberry Pi 3 is readily available for just a few Euros, so you may
> want to pick up one of those.  My most recent speed improvements for the
> Raspberry Pi's SPI and DMA drivers went into v5.4, so be sure to use at
> least that.

This is based off linux-next, so that shouldn't be a problem.

I'll try to set up the RPi3 and see if that's any better.

> Should signal quality be a problem, it's possible to
> increase GPIO drive strength by putting a dt-blob.bin in the /boot
> partition:
> 
> https://www.raspberrypi.org/documentation/configuration/pin-configuration.md
> 
> I forgot to test whether reading the MAC address from the external
> EEPROM works with v3 of your series, but I'll be back in the office
> on Tuesday to take another look.

While you're at it, can you take a look at the latency ?
I think you should be able to git-bisect it rather easily.
Thanks