Received-SPF: pass (google.com: domain of linux-kernel+bounces-183141-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Sun, 19 May 2024 17:31:16 +0200
From: Andrew Lunn <andrew@lunn.ch>
To: Siddharth Vadapalli <s-vadapalli@ti.com>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, corbet@lwn.net, rogerq@kernel.org,
	danishanwar@ti.com, vladimir.oltean@nxp.com, netdev@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, vigneshr@ti.com,
	misael.lopez@ti.com, srk@ti.com
Subject: Re: [RFC PATCH net-next 01/28] docs: networking: ti: add driver doc
 for CPSW Proxy Client
Message-ID: <642c8217-49fe-4c54-8d62-9550202c02c9@lunn.ch>
References: <20240518124234.2671651-1-s-vadapalli@ti.com>
 <20240518124234.2671651-2-s-vadapalli@ti.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240518124234.2671651-2-s-vadapalli@ti.com>

On Sat, May 18, 2024 at 06:12:07PM +0530, Siddharth Vadapalli wrote:
> The CPSW Proxy Client driver interfaces with Ethernet Switch Firmware on
> a remote core to enable Ethernet functionality for applications running
> on Linux. The Ethernet Switch Firmware (EthFw) is in control of the CPSW
> Ethernet Switch on the SoC and acts as the Server, offering services to
> Clients running on various cores.

I'm not sure we as a community what this architecture. We want Linux
to be driving the hardware, not firmware. So expect linux to be
running the server.

> +The "am65-cpsw-nuss.c" driver in Linux at:
> +drivers/net/ethernet/ti/am65-cpsw-nuss.c
> +provides Ethernet functionality for applications on Linux.
> +It also handles both the control-path and data-path, namely:
> +Control => Configuration of the CPSW Peripheral
> +Data => Configuration of the DMA Channels to transmit/receive data

So nuss is capable of controlling the hardware. nuss has an upper
interface which is switchdev, and a lower interface which somehow acts
on the hardware, maybe invoking RPCs into the firmware?

So it is not too big a step to put the server functionality in Linux,
on top of the nuss driver.

Now take a step backwards. This concept of a switch with different
CPUs attached to it is nothing special.

Some Marvell switches have a Z80 connected to a dedicated port of the
switch. You can run applications on that Z80. Those applications might
be as simple as spanning tree, so you can have a white box 8 port
ethernet switch without needing an external CPU. But there is an SDK,
you could run any sort of application on the Z80.

The microchip LAN996x switch has a Cortex A7 CPU, but also a PCIe
interface. Linux can control the switch via the PCIe interface, but
there could also be applications running on the Cortex.

Look at the Broadcom BCM89586M:
https://docs.broadcom.com/doc/89586M-PB

It is similar to the microchip device, an M7 CPU, and a PCIe
interface. It seems like a Linux host could be controlling the switch
via PCIe, and applications running on the M7.

I expect there are more examples, but you get the idea.

A completely different angle to look at is VF/PF and eswitches. A
server style CPU running virtual machines, a VM getting a VF passed
through to it. This is not something i know much about, so we might
need to pull in some data centre specialists. But we have a different
CPU, a virtual CPU, making use of part of the switch. Its the same
concept really.

My main point is, please start with an abstract view of the problem. A
lot of the solution should be generic, it can be applied to all these
devices. And then there probably needs to be a small part which is
specific to TI devices. It could be parts of the solutions already
exist, e.g. VF/PF have port represents, which might be a useful
concept here as well. Switchdev exists and provides a generic
interface for configuring switches...

	Andrew