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

Oliver Hartkopp
2021-06-30T07:27:24Z

On 29.06.21 21:39, Harald Mommer wrote:

> I still don't get it. This service process is the virtio device itself.
> All our virtio devices are user land processes. There is no problem,
> this works that way.

Works this way ... well, AFAIK virtio devices are usually no user space
implementations.

> The problem may be that the virtio device should better not have used
> vcan0 to get CAN access and that it should have used something different
> instead. CAN GW? Is it that what you want to tell me all the time? "Do
> not use vcan0 to exchange CAN messages but use CAN GW"?

You would still still use vcan0 or whatever you name it. But the
"routing between CAN interfaces" can be done more efficiently inside the
kernel.

> In this case in
> the picture the box "Device Linux / VCAN / vcan0" changes but not the
> userland virtio CAN device service process box.

My suggestion is more like: Create a virtual CAN device that exposes the
virtio net driver as a CAN device inside kernel space.

An then you can use can-gw to do filtering/firewalling/forwarding to
different application specific vcan's with can-gw.

> If it's this I'll get into CAN GW to understand what all this means now
> and how to use it.

Just try this (as root):

modprobe can-gw

cangw -A -s vcan0 -d vcan1 -e
cangw -A -s vcan0 -d vcan2 -e -m OR:ID:400.8.8888888888888888

cangen vcan0

(and candump -c -c any on a second terminal)

This should give an impression. No filtering shown.

> But anyway, if so this should not have any impact on the driver or the
> spec, this would be an issue of the device implementation itself which
> is closed source and should now not be this interesting.

IMO a CAN virtio driver can be from public interest - and it has no USP.
So why putting such a simple thing under closed source?

Regards,
Oliver

ps. Some can-gw / CAN net namespace slideware: