Hello Marc,
I sent a RFC patch which enables the local echo on vxcan interfaces by
simply removing the IFF_ECHO flag which is set by default.
With this solution we make use of the echo functionality in can_send()
which is used by slcan and vcan by default.
This approach sends the echo'ed frame instantly without checking whether
the frame has been delivered to the peer interface in the other namespace.
I don't know whether it's worth the effort to handle the local echo in
vxcan_xmit() for that 'successful delivery' feature?!?
At least vxcan feels more natural with this patch.
Best regards,
Oliver
On 01.06.21 10:50, Oliver Hartkopp wrote:
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
