linux-kernel - [RFC PATCH net-next 0/2] RPMsg based shared memory ethernet driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Tue, 30 Jan 2024 16:39:42 +0530
From: Ravi Gunasekaran <r-gunasekaran@...com>
To: <davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
        <pabeni@...hat.com>, <andrew@...n.ch>, <rogerq@...nel.org>
CC: <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <s-vadapalli@...com>, <srk@...com>, <r-gunasekaran@...com>
Subject: [RFC PATCH net-next 0/2] RPMsg based shared memory ethernet driver

virtio-net provides a solution for virtual ethernet interface in a
virtualized environment.

There might be a use-case for 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.

One solution for such an use case where the ethernet controller does
not support DMA for Tx/Rx channel, could be a RPMsg based shared memory
ethernet driver. The data plane is over the shared memory while the control
plane is over RPMsg end point channel.

Two separate regions can be carved out in the shared memory, one for the
A53 -> R5 data path, and other for R5 -> A53 data path.

The shared memory layout is as below, with the region between
PKT_1_LEN to PKT_N modelled as circular buffer.

-------------------------
|	   HEAD		|
-------------------------
|	   TAIL		|
-------------------------
|	PKT_1_LEN	|
|	  PKT_1		|
-------------------------
|	PKT_2_LEN	|
|	  PKT_2		|
-------------------------
|	    .		|
|	    .		|
------------------------
|	PKT_N_LEN	|
|	  PKT_N		|
 -----------------------

Polling mechanism can used to check for the offset between head and
tail index to process the packets by both the cores.

I initially intended to post this as a query to know whether a
RPMsg based shared memory ethernet driver would be an upstream
friendly solution or not. But then decided to do some prototyping
and share it as RFC hoping the code might help a bit in understanding
the approach.

There is still quite a handful of work to be done. As of now firmware
just helps in registering the RPMsg driver on Linux by announcing the
RPMsg device ID.

For the purpose of testing, I allocated the memory in Linux and the Tx packet
is injected back into the network stack. These test code snippets are under
TEST_DEBUG macro.

Could you all please share your opinion on this approach?
I wanted to get the community feedback before proceeding into further implementation.

Please note, I have not included the Makefile, Kconfig in this series.

Ravi Gunasekaran (2):
  net: ethernet: ti: Introduce inter-core-virt-eth as RPMsg driver
  net: ethernet: ti: inter-core-virt-eth: Register as network device

 drivers/net/ethernet/ti/inter-core-virt-eth.c | 455 ++++++++++++++++++
 drivers/net/ethernet/ti/inter-core-virt-eth.h | 105 ++++
 2 files changed, 560 insertions(+)
 create mode 100644 drivers/net/ethernet/ti/inter-core-virt-eth.c
 create mode 100644 drivers/net/ethernet/ti/inter-core-virt-eth.h

-- 
2.17.1