From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Marc Kleine-Budde <mkl@pengutronix.de>,
linux-can <linux-can@vger.kernel.org>
Subject: Re: vxcan RX/TX/echo semantics
Date: Tue, 1 Jun 2021 10:50:13 +0200 [thread overview]
Message-ID: <ebaf846a-f325-80fd-f926-6ad9854bf453@hartkopp.net> (raw)
In-Reply-To: <20210527150759.az3lal4vnhivwhlx@pengutronix.de>
Hello Marc,
On 27.05.21 17:07, Marc Kleine-Budde wrote:
> I was wondering what the RX, TX and echo semantics on vxcan interfaces
> should be.
>
> I have started a "cangen" in one namespace and a "candump" in other.
>
> The "candump" in the receiving namespace shows the CAN frames as "TX"
> and in the sending namespace the CAN frames don't show up in a "candump"
> at all. Is this intentional? If so what's the idea behind this and is
> this documented?
>
> I'm adding "cangw" to the mix and see what happens....
Yes. That is needed ...
If you take a look at slide 19 here:
https://wiki.automotivelinux.org/_media/agl-distro/agl2018-socketcan.pdf
The difference to vcan's (which are providing a local echo
functionality) the vxcan's are more like veth's:
Providing a link between two namespaces but nothing more.
The question is if it would make sense to provide an additional local
echo in vxcan_xmit() when sending to a vxcan?
When deriving vxcan from veth I probably had a some weird thoughts why
that local echo could add problems. But while looking at it now,
creating a second skb for a local echo on the side where the CAN frame
is put into the vxcan seems applicable.
What do you think?
Best,
Oliver
next prev parent reply other threads:[~2021-06-01 8:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-27 15:07 vxcan RX/TX/echo semantics Marc Kleine-Budde
2021-06-01 8:50 ` Oliver Hartkopp [this message]
2021-06-19 11:23 ` Oliver Hartkopp
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=ebaf846a-f325-80fd-f926-6ad9854bf453@hartkopp.net \
--to=socketcan@hartkopp.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.