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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Automotive Discussions]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [CAN Bus]

  Powered by Linux