socketcan send buffering

[bryancole]

Hi,

I'm developing a socketcan app which needs to write some high-priority CAN frames concurrently with writing a large number of lower priority background frames. It is important for the app that the low-priority frames don't delay the high-priority ones (classic case of priority-inversion). I'm trying to understand what buffers exist (from the hardware level through to userspace). I had planned to use the linux prio qdisc to achieve message prioritisation on the software-side. This sort-of almost works. However, there seems to be a buffer of at least 20-30 frames which always acts as a fifo (and hence if it is full of low-priority frames, these can block the high-priority ones). Maybe this is the device driver tx-buffer. I've tried playing with "ip link set can0 txqueuelen 1000" etc. and this doesn't seem to make any difference. Finally, the relationship between txqueuelen and setting setsocketopt SO_SNDBUF is pretty hard to understand. Is there a way to configure the driver tx-buffer?

I'm using a PCAN-USB device on a real (i.e. not a VM) host. uname -a gives: Linux 5.6.16-300.fc32.x86_64 #1 SMP Thu Jun 4 18:08:38 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Can anyone explain to me what buffers are in play in a socketcan system, writing to a CAN_RAW socket?
Can anyone explain what the default buffer sizes are for qdisc prio? I think this exist at the layer above the driver send buffer.

Any insight would be much appreciated.
Thanks.

[PEAK-Support]

For the SocketCAN/NetDev driver you need to contact the SocketCan community directly.
There is a Majordomo lists that you could contact - there you will find also the maintainer/base developer of the Socket CAN driver (like Oliver Hartkopp).
They deffinitally could help to answer your questions in details please see here: http://vger.kernel.org/vger-lists.html#linux-can

For the PEAK-USB Hardware:
This is depending on the used Version - older units use the SJA1000 CAN Core, newer (CAN-FD) use our own FPGA Implementation (SJA1000 "based" but extremly extened and able to handle CAN-FD)