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

On Tue, Apr 14, 2020 at 08:20:10PM +0200, Marek Vasut wrote:
> NOTE: The V4 is now tested on RPi3B with KSZ8851SNL DEMO Board at 25 MHz.
>       The "ping -c 1000 -i 0.01" latency test is fluctuating around
>       		rtt min/avg/max/mdev = 1.448/1.540/1.699/0.030 ms
>       either way, with or without this series.

Compiling this series fails if CONFIG_KS8851=m and CONFIG_KS8851_MLL=y:

arm-linux-gnueabihf-ld: drivers/net/ethernet/micrel/ks8851_common.o:(__param+0x4): undefined reference to `__this_module'

I already reported this in my e-mail of April 6th, it's caused by the
module_param_named() for msg_enable.


Reading the MAC address from an external EEPROM works with this series.


I still get worse performance with this series than without it
(perhaps unsurprisingly so because not much has changed from v3 to v4).

We're using CONFIG_PREEMPT_RT_FULL=y.  I'm sorry for not mentioning this
earlier, I didn't assume it would make such a big difference but
apparently it does.

This is the branch I've tested today:
https://github.com/l1k/linux/commits/revpi-4.19-marek-v4


Latency without this series (ping -A -c 100000):
rtt min/avg/max/mdev = 0.793/1.694/2.321/0.044 ms, ipg/ewma 2.000/1.691 ms

Latency with this series:
rtt min/avg/max/mdev = 0.957/1.715/2.652/0.043 ms, ipg/ewma 2.000/1.716 ms


RX throughput without this series (iperf3 -f k -i 0 -c):
[  5]   0.00-10.00  sec  19.0 MBytes  15960 Kbits/sec                  receiver

RX throughput with this series:
[  5]   0.00-10.00  sec  18.5 MBytes  15498 Kbits/sec                  receiver


TX throughput without this series (iperf3 -R -f k -i 0 -c):
[  5]   0.00-10.00  sec  18.6 MBytes  15614 Kbits/sec                  receiver

TX throughput with this series:
[  5]   0.00-10.00  sec  18.3 MBytes  15371 Kbits/sec                  receiver

So this is pretty much the same performance degredation as before.


> > 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 ?

Will do.


> > 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.

Hm, so why did it work with the RasPi but not with the others?

Thanks,

Lukas