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

[Harald Mommer <hmo@opensynergy.com>]

Hello Oliver,

Am 24.06.21 um 20:45 schrieb Oliver Hartkopp:
>
> What is this 'device application' in the sketch below?
The device application provides the virtio CAN device. It provides a 
virtio CAN device using an existing CAN device (here vcan).
>
>>> Can you sketch a quick block diagram showing guest, host, Virtio 
>>> device,
>>> Virtio driver, etc...
>>
>> I hope this arrives on the list as is been sent and not garbled:
>>
>>       Guest 2                    | Guest3
>> ----------------                | ----------------
>> ! cangen,      !                | ! cangen,      !
>> ! candump,     !                | ! candump,     !
>> ! cansend      !                | ! cansend      !
>> ! using vcan0  !                | ! using can0   !
>> ----------------                | ----------------
>>   ^                              |             ^
>>   !  ---------------------       |             !
>>   !  ! Service process   !       |             !
>>   !  ! in user space     !       |             !
>>   !  ! virtio-can device !       |             !
>>   !  ! forwarding vcan0  !       |             !
>>   !  ---------------------       |             !
>
> Hopefully not this "Service process in user space" ???
The virtio CAN device is the "Service process in user space".
>
> If so, this is a very questionable approach!
>
> To route/forward/manipulate CAN frames between CAN network interfaces
> there is a CAN gateway module 'can-gw' which can be controlled over
> PF_NETLINK.
>
> The can-gw runs super efficient and fast inside kernel space in the
> SOFTIRQ context.
>
> E.g. 22.000 CAN frames/s with 6% sys load on a 2 core i7 from 2012,
> here: https://youtu.be/O3eOjfTl1yk?t=89
>
> Just type cangw from the can-utils to get an impression of the powerful
> options.
>
> You can even calculate E2E CRCs and XOR checksums after doing content
> mods on the fly.
>
>>   ! ^               ^         |             !
>>   !    !               !         |             !
>> --------------------------------------------------
>>   !    !   Device side ! kernel  | Driver side ! kernel
>>   v    v               v         |             v
>> ---------------- -------------- | ----------------
>> ! Device Linux ! ! HV support ! | ! Driver Linux !
>> !    VCan      ! !   module   ! | !  Virtio CAN  !
>> !    vcan0     ! ! on device  ! | !     can0     !
>> !              ! !   side     ! | !              !
>> ---------------- -------------- | ----------------
>>         ^               ^        |        ^
>>         !               !        |        !
>> --------------------------------------------------
>>         !               !                 ! Hypervisor
>>         v               v                 v
>> --------------------------------------------------
>> !                     COQOS-HV                   !
>> --------------------------------------------------
>>
>
> (..)
>
>> can be handled. Need the command line switch anyway now to do 
>> experiments.
>
> Now with cangw ?!? ;-)

No. We cannot do this here with something which already exists like CAN 
GW. We are not talking about user processes running on the same Linux 
instance which want to communicate to each other. This might have been 
the misunderstanding here.

We are talking about two different virtual machines both running 
different OS instances under a hypervisor! And one or two VMs may not 
even run Linux as the OS. The device VM could in a future setup run 
under an RTOS using maybe an AUTOSAR CAN driver as backend which might 
even come from a 3rd party.

In the current setup we have 2 VMs running different instances of Linux 
on the same physical machine under hypervisor control. Only the left VM, 
the device VM has access to any hardware (like a CAN controller). The 
right VM has no direct access to any hardware at all. To be able to send 
and receive frames in the right (driver) VM we have to do something to 
be able to get out to the external world. Currently there exists nothing 
to do this for CAN so we must do the new virtio CAN device which allows 
the access to a (physical) CAN controller via Virtio means.

>
> Regards,
> Oliver
>
Regards
Harald