On 18.06.21 11:16, Marc Kleine-Budde wrote:
Even if the Linux Kernel doesn't drop any messages, not all CAN
controllers support that feature. On the Linux side we try our best, but
some USB attached devices don't report a TX complete event back, so the
driver triggers the CAN echo skb after the USB transfer has been
completed.
We don't have a feature flag to query if the Linux driver support proper
CAN echo on TX complete notification.
We have. It is set in struct netdevice.flags and called IFF_ECHO.
https://elixir.bootlin.com/linux/v5.12.11/source/net/can/af_can.c#L257
E.g. the slcan driver does not have this bit set.
Regards,
Oliver
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.
Do you have some code available yet?
regards,
Marc
