Am 07.05.21 um 10:25 schrieb Marc Kleine-Budde:

On 07.05.2021 08:21:57, Patrick Menschel wrote:

quoted

quoted

quoted

quoted

Would it be possible for you to pull these patches into a v5.10 branch
in your linux-rpi repo [1]?

Here you are:

https://github.com/marckleinebudde/linux-rpi/tree/v5.10-rpi/backport-performance-improvements

I've included the UINC performance enhancements, too. The branch is compiled
tested only, though. I'll send a pull request to the rpi kernel after I've
testing feedback from you.

Drew, Patrick, have you tested this branch? If so I'll send a pull
request to the raspi kernel.

quoted

not yet. Thanks for reminding me. I'll start a native build on a pi0w asap.

Is there any test application or stress test that I should run?

No, not any particular, do your normal (stress) testing.

Following up on this.

Build and test finished on a pi0w.

### Test conditions ###

Since I lacked a true stress test, I wrote one for regular tox with
pytest collection.

https://gitlab.com/Menschel/socketcan/-/blob/master/tests/test_socketcan.py#L872

It uses mcp0 and mcp1 which are directly connected.
No CAN FD, just 500k with regular frames, random id and random data.

I basically mimic cangen but enhanced with a queue that handles to the
rx thread what should be compared next.

### Extract from dmesg shows no CRC Errors ###

[   30.930608] CAN device driver interface
[   30.967349] spi_master spi0: will run message pump with realtime priority
[   31.054202] mcp251xfd spi0.1 can0: MCP2518FD rev0.0 (-RX_INT
-MAB_NO_WARN +CRC_REG +CRC_RX +CRC_TX +ECC -HD c:40.00MHz m:20.00MHz
r:17.00MHz e:16.66MHz) successfully initialized.
[   31.076906] mcp251xfd spi0.0 can1: MCP2518FD rev0.0 (-RX_INT
-MAB_NO_WARN +CRC_REG +CRC_RX +CRC_TX +ECC -HD c:40.00MHz m:20.00MHz
r:17.00MHz e:16.66MHz) successfully initialized.
[   31.298969] mcp251xfd spi0.0 mcp0: renamed from can1
[   31.339864] mcp251xfd spi0.1 mcp1: renamed from can0
[   33.471889] IPv6: ADDRCONF(NETDEV_CHANGE): mcp0: link becomes ready
[   34.482260] IPv6: ADDRCONF(NETDEV_CHANGE): mcp1: link becomes ready
[  215.218979] can: controller area network core
[  215.219146] NET: Registered protocol family 29
[  215.261599] can: raw protocol
[  218.745376] can: isotp protocol
[  220.931150] NOHZ tick-stop error: Non-RCU local softirq work is
pending, handler #08!!!
[  220.931274] NOHZ tick-stop error: Non-RCU local softirq work is
pending, handler #08!!!
[  220.931395] NOHZ tick-stop error: Non-RCU local softirq work is
pending, handler #08!!!
[  220.931518] NOHZ tick-stop error: Non-RCU local softirq work is
pending, handler #08!!!
[  220.931643] NOHZ tick-stop error: Non-RCU local softirq work is
pending, handler #08!!!
[  220.931768] NOHZ tick-stop error: Non-RCU local softirq work is
pending, handler #08!!!
[  220.931893] NOHZ tick-stop error: Non-RCU local softirq work is
pending, handler #08!!!
[  222.099822] NOHZ tick-stop error: Non-RCU local softirq work is
pending, handler #08!!!
[  222.099901] NOHZ tick-stop error: Non-RCU local softirq work is
pending, handler #08!!!
[  222.100022] NOHZ tick-stop error: Non-RCU local softirq work is
pending, handler #08!!!
[  222.330438] can: broadcast manager protocol

That softirq error has something to do with IsoTp. I was not able to
trace it back but I have it on multiple boards: pi0w, pi3b, pi3b+.


### Performance ###

## v5.10-rpi/backport-performance-improvements ##

I get about 20000 frames in 2 minutes.

2021-05-08 19:00:36 [    INFO] 20336 frames in 0:02:00
(test_socketcan.py:890)

2021-05-08 19:49:34 [    INFO] 20001 frames in 0:02:00
(test_socketcan.py:890)


## regular v5.10 ##

2021-05-08 20:19:55 [    INFO] 20000 frames in 0:02:00
(test_socketcan.py:890)

2021-05-08 20:22:40 [    INFO] 19995 frames in 0:02:00
(test_socketcan.py:890)

2021-05-08 20:25:22 [    INFO] 19931 frames in 0:02:00
(test_socketcan.py:890)


The numbers are slightly better but I count that as tolerance. I also
found that there are cross effects. If I run the same test on vcan0
before, the frame count goes down to 13000 instead.

I also have to admit, that I didn't get any crc errors with regular
v5.10 during that tests.

Do I have to change my test?

I can still update that pi3b+ that runs my micro-hil at work. That was
the one that occasionally had CRC errors.

Best Regards,
Patrick