Re: [PATCH V4 00/19] net: ks8851: Unify KS8851 SPI and MLL drivers

From: Marek Vasut <marex@denx.de>
To: Lukas Wunner <lukas@wunner.de>
Cc: netdev@vger.kernel.org, "David S . Miller" <davem@davemloft.net>,
	Petr Stetiar <ynezz@true.cz>, YueHaibing <yuehaibing@huawei.com>
Subject: Re: [PATCH V4 00/19] net: ks8851: Unify KS8851 SPI and MLL drivers
Date: Wed, 15 Apr 2020 16:51:39 +0200	[thread overview]
Message-ID: <ac0f7227-a4ae-b6cd-36ec-3bcb02b1adbe@denx.de> (raw)
In-Reply-To: <20200415143909.wmtmud3vkkwzjv73@wunner.de>

On 4/15/20 4:39 PM, Lukas Wunner wrote:
> 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).

I reinstated the indirect access, so things did change. Besides, there
performance for the parallel option is back where it was with the old
driver, which is important for me.

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

Do you also have the RT patch applied ?

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

You seem to have quite a few more patches in that repository than just
this series, some of them even touching the RPi SPI driver and it's DMA
implementation.

Could it be that's why I don't see your performance problems too ?

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

Thanks

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

I didn't have a chance to debug this yet.