Am 07.05.21 um 10:25 schrieb Marc Kleine-Budde: > On 07.05.2021 08:21:57, Patrick Menschel wrote: >>>>> 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. >>> > >> 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
