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

[Harald Mommer <hmo@opensynergy.com>]

[Re-sent because some mechanism on the mailing list thought this was 
SPAM and rejected.
Looks like the list does not like when Thunderbird composes a HTML 
E-Mail. Setting changed & retry.]

Hello,

Am 25.06.21 um 11:39 schrieb Marc Kleine-Budde:
> It makes sense to have a TX done notification. You probably need this
> for proper queue handling and throttling.
Yes. But this acknowledgements must be 100% reliable under all possible 
load conditions otherwise testers will prove that the solution does only 
work when the sun is shining but not during bad weather.
>
>>> 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     !       |             !
> Oliver has already commented on this :) Getting feedback from the
> community early could have saved you some work :)

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.

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"? In this case in 
the picture the box "Device Linux / VCAN / vcan0" changes but not the 
userland virtio CAN device service process box.

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

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.

>>   !  ! virtio-can device !       |             !
>>   !  ! forwarding vcan0  !       |             !
>>   !  ---------------------       |             !
>>   !    ^               ^         |             !
>>   !    !               !         |             !
>> --------------------------------------------------
>>   !    !   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                   !
>> --------------------------------------------------
>>
>>
> IC - as I'm not interested in closed source solution I'd focus on the
> qemu use case. Good thing is, the virtio-can must handle both use cases
> anyways.
For me qemu is in this moment an unknown environment to develop for. 
There are already some challenges in this project and at some point 
there are too much challenges. Have to discuss if/how qemu is to be 
addressed.
> Your user space bridge is the wrong solution here.....See Oliver's mail.
The virtio devices are always user land processes in our architecture. 
Only what exactly is to be bridged is the question.
>> Nothing which should be done now, getting far too complicated for a 1st shot
>> to implement a Virtio CAN device.
>>
>>> We don't have a feature flag to query if the Linux driver support proper
>>> CAN echo on TX complete notification.
>> Not so nice. But the device integrator should know which backend is used and
>> having a command line option for the device application the issue can be
>> handled. Need the command line switch anyway now to do experiments.
> If needed we can add flags to the CAN drivers so that they are
> introspectable, maybe via the ethtool interface.
I understand here that nothing is etched in stone for all time. Did not 
expect that something like this could be possible.
> Marc

Harald