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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200517191635.GE606317@lunn.ch>
Date:   Sun, 17 May 2020 21:16:35 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Lukas Wunner <lukas@...ner.de>
Cc:     David Miller <davem@...emloft.net>, marex@...x.de,
        netdev@...r.kernel.org, ynezz@...e.cz, yuehaibing@...wei.com
Subject: Re: [PATCH V6 00/20] net: ks8851: Unify KS8851 SPI and MLL drivers

> However in terms of performance there's a bigger problem:
> 
> Previously ks8851.c (SPI driver) had 8-bit and 32-bit register accessors.
> The present series drops them and performs a 32-bit access as two 16-bit
> accesses and an 8-bit access as one 16-bit access because that's what
> ks8851_mll.c (16-bit parallel bus driver) does.  That has a real,
> measurable performance impact because in the case of 8-bit accesses,
> another 8 bits need to be transferred over the SPI bus, and in the case
> of 32-bit accesses, *two* SPI transfers need to be performed.

How often does this happen on a per packet basis? Packets are
generally a mixture of 50bytes, 576bytes and 1500bytes in size, with
the majority being 576 bytes. Does an extra 8 or 16 bits per packet
really make that much difference? Or is the real problem the overheads
of doing the transaction, not the number of bytes transferred? If so,
maybe the abstractions needs to be slightly higher, not register
access, but basic functionality.

> Nevertheless I was going to repeat the performance measurements on a
> recent kernel but haven't gotten around to that yet because the
> measurements need to be performed with CONFIG_PREEMPT_RT_FULL to
> be reliable (a vanilla kernel is too jittery), so I have to create
> a new branch with RT patches on the test machine, which is fairly
> involved and time consuming.

I assume you will then mainline the changes, so you don't need to do
it again? That is the problem with doing development work on a dead
kernel.

	Andrew