On 23.03.2022 13:28:20, Thomas.Kopp@microchip.com wrote:
> > this series for the mcp251xfd adds IRQ coalescing support.
>
> Thanks for these patches, the performance gains with activated
> coalescing look awesome!

\o/

> Testing on a Pi4 mostly 1 channel RX-only Full busload scenarios I see
> significantly reduced CPU utilization. This is both for CAN 2.0 and
> CAN-FD use-cases.

\o/

> I tested this patch series against 5.17 mainline

Thanks for testing.
Does the coalescing series apply to v5.17 without the other series?

> 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?

> 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.

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |