[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
