netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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>,
	Andrew Lunn <andrew@lunn.ch>
Subject: Re: [PATCH V2 00/14] net: ks8851: Unify KS8851 SPI and MLL drivers
Date: Fri, 27 Mar 2020 19:18:38 +0100	[thread overview]
Message-ID: <44b7417b-42d6-cb13-89a7-17b75905e75d@denx.de> (raw)
In-Reply-To: <20200326190219.zwu2qgu6f6lxbied@wunner.de>

On 3/26/20 8:02 PM, Lukas Wunner wrote:
> On Wed, Mar 25, 2020 at 04:05:29PM +0100, Marek Vasut wrote:
>> The KS8851SNL/SNLI and KS8851-16MLL/MLLI/MLLU are very much the same pieces
>> of silicon, except the former has an SPI interface, while the later has a
>> parallel bus interface. Thus far, Linux has two separate drivers for each
>> and they are diverging considerably.
>>
>> This series unifies them into a single driver with small SPI and parallel
>> bus specific parts. The approach here is to first separate out the SPI
>> specific parts into a separate file, then add parallel bus accessors in
>> another separate file and then finally remove the old parallel bus driver.
>> The reason for replacing the old parallel bus driver is because the SPI
>> bus driver is much higher quality.
> 
> With this series, ks8851.ko (SPI variant) failed to compile as a module.
> I got it working by renaming ks8851.c to ks8851_common.c and applying
> the following change to the Makefile:
> 
> --- a/drivers/net/ethernet/micrel/Makefile
> +++ b/drivers/net/ethernet/micrel/Makefile
> @@ -5,6 +5,8 @@
>  
>  obj-$(CONFIG_ARM_KS8695_ETHER) += ks8695net.o
>  obj-$(CONFIG_KS8842) += ks8842.o
> -obj-$(CONFIG_KS8851) += ks8851.o ks8851_spi.o
> -obj-$(CONFIG_KS8851_MLL) += ks8851.o ks8851_par.o
> +obj-$(CONFIG_KS8851) += ks8851.o
> +ks8851-objs = ks8851_common.o ks8851_spi.o
> +obj-$(CONFIG_KS8851_MLL) += ks8851_mll.o
> +ks8851_mll-objs = ks8851_common.o ks8851_par.o
>  obj-$(CONFIG_KSZ884X_PCI) += ksz884x.o
> 
> This series breaks reading the MAC address from an EEPROM attached to
> the KSZ8851SNLI:
> The MAC address stored in the EEPROM was c8:3e:a7:99:ef:aa.
> The MAC address was read as 3e:c8:99:a7:ef:aa with this series.
> Note: The MAC address starts at the third byte in the EEPROM and is
> stored as aa:ef:99:a7:3e:c8, i.e. in reverse order.  (I think the
> spec says something else but it appears to be wrong.)
> 
> Assigning a MAC address with "ifconfig eth1 hw ether <mac>" (which I
> believe ends up calling ks8851_write_mac_addr()) worked fine.

I added fixes for those.

> The performance degredation with this series is as follows:
> 
> Latency (ping) without this series:
>   rtt min/avg/max/mdev = 0.982/1.776/3.756/0.027 ms, ipg/ewma 2.001/1.761 ms
> With this series:
>   rtt min/avg/max/mdev = 1.084/1.811/3.546/0.040 ms, ipg/ewma 2.020/1.814 ms
> 
> Throughput (scp) without this series:
>   Transferred: sent 369780976, received 66088 bytes, in 202.0 seconds
>   Bytes per second: sent 1830943.5, received 327.2
> With this series:
>   Transferred: sent 369693896, received 67588 bytes, in 210.5 seconds
>   Bytes per second: sent 1755952.6, received 321.0

Maybe some iperf would be better here ?

> SPI clock is 25 MHz.  The chip would allow up to 40 MHz, but the board
> layout limits that.
> 
> I suspect the performance regression is not only caused by the
> suboptimal 16 byte instead of 8 byte accesses (and 2x16 byte instead
> of 32 byte accesses), but also because the accessor functions cannot
> be inlined.  It would be better if they were included from a header
> file as static inlines.  The performance regression would then likely
> disappear.

I did another measurement today and I found out that while RX on the old
KS8851-MLL driver runs at ~50 Mbit/s , TX runs at ~80 Mbit/s . With this
new driver, RX still runs at ~50 Mbit/s, but TX runs also at 50 Mbit/s .
That's real bad. Any ideas how to debug/profile this one ?

> I guess the good news is that it otherwise worked out of the box.

Great

  reply	other threads:[~2020-03-27 18:22 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-25 15:05 [PATCH V2 00/14] net: ks8851: Unify KS8851 SPI and MLL drivers Marek Vasut
2020-03-25 15:05 ` [PATCH V2 01/14] net: ks8851: Factor out spi->dev in probe()/remove() Marek Vasut
2020-03-25 15:05 ` [PATCH V2 02/14] net: ks8851: Rename ndev to netdev in probe Marek Vasut
2020-03-25 15:05 ` [PATCH V2 03/14] net: ks8851: Replace dev_err() with netdev_err() in IRQ handler Marek Vasut
2020-03-25 15:05 ` [PATCH V2 04/14] net: ks8851: Pass device node into ks8851_init_mac() Marek Vasut
2020-03-25 15:05 ` [PATCH V2 05/14] net: ks8851: Use devm_alloc_etherdev() Marek Vasut
2020-03-25 15:05 ` [PATCH V2 06/14] net: ks8851: Use dev_{get,set}_drvdata() Marek Vasut
2020-03-25 15:05 ` [PATCH V2 07/14] net: ks8851: Remove ks8851_rdreg32() Marek Vasut
2020-03-25 15:05 ` [PATCH V2 08/14] net: ks8851: Use 16-bit writes to program MAC address Marek Vasut
2020-03-25 16:56   ` Michal Kubecek
2020-03-25 17:05     ` Marek Vasut
2020-03-25 17:30       ` Michal Kubecek
2020-03-27 18:16         ` Marek Vasut
2020-03-25 15:05 ` [PATCH V2 09/14] net: ks8851: Use 16-bit read of RXFC register Marek Vasut
2020-03-25 15:05 ` [PATCH V2 10/14] net: ks8851: Split out SPI specific entries in struct ks8851_net Marek Vasut
2020-03-25 15:05 ` [PATCH V2 11/14] net: ks8851: Split out SPI specific code from probe() and remove() Marek Vasut
2020-03-25 15:05 ` [PATCH V2 12/14] net: ks8851: Separate SPI operations into separate file Marek Vasut
2020-03-25 15:05 ` [PATCH V2 13/14] net: ks8851: Implement Parallel bus operations Marek Vasut
2020-03-25 15:05 ` [PATCH V2 14/14] net: ks8851: Remove ks8851_mll.c Marek Vasut
2020-03-26 19:02 ` [PATCH V2 00/14] net: ks8851: Unify KS8851 SPI and MLL drivers Lukas Wunner
2020-03-27 18:18   ` Marek Vasut [this message]
2020-03-27 19:25     ` Marek Vasut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44b7417b-42d6-cb13-89a7-17b75905e75d@denx.de \
    --to=marex@denx.de \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=lukas@wunner.de \
    --cc=netdev@vger.kernel.org \
    --cc=ynezz@true.cz \
    --cc=yuehaibing@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).