Hello, Am 02.08.19 um 13:07 schrieb Marc Kleine-Budde: > On 8/2/19 1:49 AM, Tom Prohaszka wrote: >> I found this for the V5 commit: If I remember correctly, the latest version of this series is V7. >> https://www.spinics.net/lists/linux-can/msg00847.html >> I may have read it wrong. It sounds like the network stack is >> dropping them, not necessarily the "statistics" gathering. >> >> Still the driver is able to handle reception of 99.95% of all CAN frames >> of a 100% saturated 1MHz Can2.0 Bus with Frames with standard IDs and >> DLC=0 on a Raspberry Pi 3. Note that this statistics is without injection >> into the network stack, which then drops about 60% of all frames. > To my understanding it's the networking stack that drops the CAN frames > not the statistics itself. Yes, the problem is that there is little CPU time left for the upper layer to process the packets. SPI keeps the system busy! Anyway, this is not a realistic CAN use-case but it clearly shows that you can overload your system easily that way. > > However I've added a Kconfig option to the driver to switch off the > debugfs support: > > https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git/log/?h=mcp25xxfd I suggested to Martin to remove all the heavy debugging and statistics stuff... or at least to make it configurable (including incrementing of the counters). I would use a dedicated CONFIG_CAN_MCP25XXFD_DEBUG_FS. CONFIG_DEBUG_FS is usually enabled. Wolfgang
