MSG_CONFIRM RX messages with SocketCAN known as unreliable under heavy load?

[Harald Mommer <hmo@opensynergy.com>]

Hello,

we are currently in the process of developing a draft specification for 
Virtio CAN. In the scope of this work I am developing a Virtio CAN Linux 
driver and a Virtio CAN Linux device running on top of our hypervisor 
solution.

The Virtio CAN Linux device forwards an existing SocketCAN CAN device 
(currently vcan) via Virtio to the Virtio driver guest so that the 
virtual driver guest can send and receive CAN frames via SocketCAN.

What was originally planned (probably with too much AUTOSAR CAN driver 
semantics in my head and too few SocketCAN knowledge) is to mark a 
transmission request as used (done) when it's sent finally on the CAN 
bus (vs. when it's given to SocketCAN not really done but still pending 
somewhere in the protocol stack).

Thought this was doable with some implementation effort using

setsockopt(..., SOL_CAN_RAW, CAN_RAW_RECV_OWN_MSGS, ...) and evaluatiing 
the MSG_CONFIRM bit on received messages.

This works fine with

cangen -g 0 -i can0

on the driver side sending CAN messages to the device guest. No 
confirmation is lost testing for several minutes.

Adding now on the device side a

cangen -g 0 -i vcan0

sending messages like crazy from the device side guest to the driver 
side guest in parallel I'm loosing TX confirmations in the Linux CAN 
stack. Seems also there is no other error indication (CAN_ERR_FLAG) that 
something like this happened. The virtio CAN device gets out of 
resources and TX will become stuck. Which is not really acceptable even 
for such a heavy load situation (-g0 on both sides).

Is CAN_RAW_RECV_OWN_MSGS / MSG_CONFIRM known as being unreliable (means 
MSG_CONFIRM messages are dropped) under extreme load situations? If so, 
is there a way to detect reliably that this happened so that somehow a 
recovery mechanism for the pending TX acknowledgements could be implemented?

I'm aware that "normal" RX messages from other nodes may be dropped due 
to overload. No problem with this.

The timing requirement originally set (done when sent on CAN bus) has to 
be weakened or put under a feature flag when it's not reliably 
implementable in all environments. But before declaring as "not reliably 
implementable with Linux SocketCAN" I would like to be sure that it's 
really that way and absolutely nothing can be done about it. Could even 
be that I missed an additional setting I'm not aware of. But the 
observed behavior may as well be something which is known to everyone 
except me.

Of course it can be that there is still a bug in my software but checked 
this carefully and I'm now convinced that under heavy load situations 
MSG_CONFIRM messages are lost somewhere in the Linux SocketCAN protocol 
stack. If there's no way to recover from this situaton I've to weaken 
the next draft Virtio CAN draft specification regarding the TX ACK 
timing. As this has some additional impact on the specification before 
doing so I would like to be really sure that the TX ACK timing cannot be 
done reliably the way it was originally planned.

Regards
Harald
-- 
Dipl.-Ing. Harald Mommer
Senior Software Engineer

OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin

Phone:  +49 (30) 60 98 540-0 <== Zentrale
Fax:    +49 (30) 60 98 540-99
E-Mail: harald.mommer@opensynergy.com

www.opensynergy.com

Handelsregister: Amtsgericht Charlottenburg, HRB 108616B
Geschäftsführer/Managing Director: Regis Adjamah