> Thanks for testing.
> Does the coalescing series apply to v5.17 without the other series?
I took the latest state of the driver from can-next testing branch(and reverted the pending patch that changes the return value from int to void) and build the .ko from those files. So I suppose I had the other series as well?
> > and I think the performance when NOT using coalescing regressed
> > slightly ("measured" via sar -u 1, not sure if that is a valid
> > benchmark?)
>
> "sar" don't know that tool, which Debian package do I have to install?
Sar from the sysstat package, again no idea whether that's a good benchmark but I didn't do any device driver benchmarking yet so that's what I found.
> > I had both driver versions configured for the same fifo sizes and
> > coalescing turned off. The mainline driver actually generates slighty
> > more SPI interrupts in this scenario (20k CAN 2.0 Frames RXed in
> > CAN-FD mode). Not really sure what causes the higher CPU utilization
> > or if it's even relevant (maybe on smaller systems than a Pi4)
>
> I don't know the length of the SPI transfers, where the raspi SPI driver
> switched from PIO to IRQ mode. If more CAN frames are read in one
> transfer (this can happen with deactivated IRQ coalescing, too) the
> transfer size might be big enough to trigger an IRQ transfer, especially
> in CAN-FD mode.
>
> For better reproducibility I set the scaling_governor to performance:
>
> | echo performance | sudo tee
> /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
>
> I've no idea why an unpachted v5.17 generates more SPI IRQs.
>
> Can you re-test with performance mode activated, I'm not sure when I
> find time to look into this.
>
Yes, will do. For the record, the difference was really marginal. On 20k frames I had 39182 vs. 39139 SPI interrupts.
Regards,
Thomas
