netdev - Re: [PATCH V6 00/20] 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]

Message-ID: <a68af5dd-d12c-f645-f89f-3967cc64e8df@denx.de>
Date:   Sun, 17 May 2020 04:27:58 +0200
From:   Marek Vasut <marex@...x.de>
To:     David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org, lukas@...ner.de, ynezz@...e.cz,
        yuehaibing@...wei.com
Subject: Re: [PATCH V6 00/20] net: ks8851: Unify KS8851 SPI and MLL drivers

On 5/17/20 4:02 AM, David Miller wrote:
> From: Marek Vasut <marex@...x.de>
> Date: Sun, 17 May 2020 02:33:34 +0200
> 
>> 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.
> 
> What strikes me in these changes is all of the new indirect jumps in
> the fast paths of TX and RX packet processing.  It's just too much for
> my eyes. :-)
> 
> Especially in the presence of Spectre mitigations, these costs are
> quite non-trivial.
> 
> Seriously, I would recommend that instead of having these small
> indirect helpers, just inline the differences into two instances of
> the RX interrupt and the TX handler.

So I was already led into reworking the entire series to do this
inlining once, after V1. It then turned out it's a horrible mess to get
everything to compile as modules and built-in and then also only the
parallel/SPI as a module and then the other way around.

Since Lukas was very adamant about the performance impact of these
indirect calls, I did measurements and it turned out the impact is
basically nonexistent. And that's pretty much to be expected, since this
is a 100 Mbit ethernet on SPI bus limited to 40 MHz (so effectively a 40
Mbit ethernet tops) or on parallel bus. The parallel bus option is the
"more performant" one and even that one shows no difference with and
without this series in iperf, either in throughput or latency.

So I spent more time and undid those changes again. And here is the V6
of the series.