Hi Andrew

On 17/09/25 10:07 pm, Andrew Davis wrote:

On 9/17/25 6:44 AM, MD Danish Anwar wrote:

quoted

Hi Andrew,

On 11/09/25 9:34 pm, Andrew Davis wrote:

quoted

On 9/11/25 6:36 AM, MD Danish Anwar wrote:

quoted

This patch series introduces the RPMSG Ethernet driver, which
provides a
virtual Ethernet interface for communication between a host
processor and
a remote processor using the RPMSG framework. The driver enables
Ethernet-like packet transmission and reception over shared memory,
facilitating inter-core communication in systems with heterogeneous
processors.

This is neat and all but I have to ask: why? What does this provide
that couldn't be done with normal RPMSG messages? Or from a userspace
TAP/TUN driver on top of RPMSG?

This is different from RPMSG because here I am not using RPMSG to do the
actual TX / RX. RPMSG is only used to share information (tx / rx
offsets, buffer size, etc) between driver and firmware. The TX / RX
happens in the shared memory. This implementation uses a shared memory

This is how RPMSG is supposed to be used, it is meant for small messages
and signaling, bulk data should be send out-of-band. We have examples
specifically showing how this should be done when using RPMSG[0], and our
RPMSG backed frameworks do the same (like DSP audio[1] and OpenVX[2]).

quoted

circular buffer with head/tail pointers for efficient data passing
without copies between cores.

quoted

This also feels like some odd layering, as RPMSG sits on virtio, and
we have virtio-net, couldn't we have a firmware just expose that (or
would the firmware be vhost-net..)?

PMSG sits on virtio, and we do have virtio-net but I am not trying to do
ethernet communication over RPMSG. RPMSG is only used to exchange
information between cores regarding the shared memory where the actual
ethernet communication happens.

Again nothing new here, virtio-net does control plane work though a
message channel but the data plane is done using fast shared memory
vqueues with vhost-net[3]. Using RPMSG would just be an extra unneeded
middle layer and cause you to re-implement what is already done with
virtio-net/vhost-net.

virtio-net provides a solution for virtual ethernet interface in a
virtualized environment. Our use-case here is traffic tunneling between
heterogeneous processors in a non virtualized environment such as TI's
AM64x that has Cortex A53 and Cortex R5 where Linux runs on A53 and a
flavour of RTOS on R5(FreeRTOS) and the ethernet controller is managed
by R5 and needs to pass some low priority data to A53. The data plane is
over the shared memory while the control plane is over RPMsg end point
channel.

We had aligned with Andrew L [1] and the ask was to create a generic
Linux Ethernet driver that can be used for heterogeneous system. Similar
to rpmsg_tty.c. It was suggested to create a new rpmsg_eth.c driver that
can be used for this purpose.

Here I have implemented what was suggested in [1]

[1]
https://lore.kernel.org/all/8f5d2448-bfd7-48a5-be12-fb16cdc4de79@lunn.ch/ (local)

Andrew

[0] https://git.ti.com/cgit/rpmsg/rpmsg_char_zerocopy
[1] https://github.com/TexasInstruments/rpmsg-dma
[2] https://github.com/TexasInstruments/tiovx
[3] https://www.redhat.com/en/blog/deep-dive-virtio-networking-and-
vhost-net

-- 
Thanks and Regards,
Danish