Thread (42 messages) flat view 42 messages, 6 authors, 2020-05-21

Re: [PATCH V6 00/20] net: ks8851: Unify KS8851 SPI and MLL drivers

From: Andrew Lunn <andrew@lunn.ch>
Date: 2020-05-17 19:16:41

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help