socketcan send buffering
Posted: Tue 9. Jun 2020, 13:40
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.
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.