From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Harald Mommer <hmo@opensynergy.com>,
Marc Kleine-Budde <mkl@pengutronix.de>
Cc: linux-can@vger.kernel.org
Subject: Re: MSG_CONFIRM RX messages with SocketCAN known as unreliable under heavy load?
Date: Wed, 30 Jun 2021 09:27:06 +0200 [thread overview]
Message-ID: <42e3018d-cb08-20b2-6890-c5e0761cceae@hartkopp.net> (raw)
In-Reply-To: <eb9a1f75-3bc9-aa07-9508-6a081be6a15c@opensynergy.com>
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:
https://wiki.automotivelinux.org/_media/agl-distro/agl2018-socketcan.pdf
next prev parent reply other threads:[~2021-06-30 7:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-29 19:39 MSG_CONFIRM RX messages with SocketCAN known as unreliable under heavy load? Harald Mommer
2021-06-30 7:27 ` Oliver Hartkopp [this message]
-- strict thread matches above, loose matches on Subject: below --
2021-06-17 12:22 Harald Mommer
2021-06-18 9:16 ` Marc Kleine-Budde
2021-06-18 18:23 ` Oliver Hartkopp
2021-06-19 21:42 ` Marc Kleine-Budde
2021-06-24 15:21 ` Harald Mommer
2021-06-24 18:45 ` Oliver Hartkopp
2021-06-28 13:47 ` Harald Mommer
2021-06-25 9:39 ` Marc Kleine-Budde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42e3018d-cb08-20b2-6890-c5e0761cceae@hartkopp.net \
--to=socketcan@hartkopp.net \
--cc=hmo@opensynergy.com \
--cc=linux-can@vger.kernel.org \
--cc=mkl@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox