On Sun, Jun 02, 2024 at 09:36:05AM +0530, Siddharth Vadapalli wrote: > On Sun, May 19, 2024 at 05:31:16PM +0200, Andrew Lunn wrote: > > Andrew, > > I have spent time going through your feedback, trying to understand your > suggestions. This email is the complete reply corresponding to my earlier > reply at: > https://lore.kernel.org/r/0b0c1b07-756e-439e-bfc5-53824fd2a61c@xxxxxx/ > which was simply meant to serve as an acknowledgement that I have seen > your email. > > > 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. > > Due to the use-case requirements, Linux cannot be the server. Some of > the requirements are: > 1. Fast startup and configuration of CPSW independent of Linux and Other > OS running on any of the cores on the SoC. The configuration of CPSW has > to be performed in parallel while the Bootloader starts Linux. > 2. CPSW has to be functional and configurable even when Linux has been > suspended. One of the non-Linux Clients happens to be the AUTOSAR Client > which continues exchanging network data via CPSW even when Linux has > been suspended. So the server has to be functional even then, in order > to cater to the AUTOSAR Client's requests to configure CPSW. CPSW's > configuration is not static in the sense that it gets programmed and > will no longer be modified. Therefore the server has to be functional at > all times to update CPSW's configuration based on the demands of any of > the Clients. > > For more details about the Ethernet Switch Firmware (EthFw) and the set > of Clients running on remote cores, please refer: > https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/09_02_00_05/exports/docs/ethfw/docs/user_guide/ethfw_c_ug_top.html#ethfw_remote_clients Thanks for the links etc. I also admit, i did replied too soon, and should of read more of the patches. In Linux, we have two models with respect to switches. 1) They are external. Linux does not interact with them, other than sending them packets, and receiving packets from them. The switch might have some management interface, SNMP, HTTP, etc, but it is not linuxs job to manage the switch. Linux just has its NIC connected to the port of switch using a cable. This is the model used for a very long time. 2) The Linux kernel is controlling the switch, configuration is performed from userspace using iproute2. Switchdev is used internally to interface between the linux network stack and the switch driver. Depending on implementation, linux can either directly write switch registers, or it can perform an RPC to firmware running on the switch. But this is an implementation detail, Linux is in control of all the ports, all the routing/switching, IGMP snooping, STP, PTP, etc. Could what Linux sees of this hardware fit into the first model? Linux just sees a bunch of NICs connected to a switch? The switch is remote, linux has no control over it. Linux acts purely as a client for low level protocols like PTP, IGMP snooping, etc. It has no knowledge of other ports of the switch, there up/down state, what STP is doing in the switch, how PTP is forwarding packets from the upstream port to the downstream ports. Linux has no idea and no access to the address lookup engines in the switch. The switch is colocated in the same silicon, but all linux has is some ports connected to the switch, nothing more? What is interesting is Realteks current driver work for there automotive system. There CPU has one MAC which is connected to the internal switch. But they have a similar setup, Linux is not controlling the switch, some other firmware is. They have PTP, IGMP snooping, STP etc running in firmware. Linux just has a NIC connected to the switch as an end system. If you do want to add a third model, where Linux has some insight into the switch, you need to coordinate with other vendors in the automotive world, and come up with a model which everybody can use. What i don't want is a TI model, followed by a Realtek model, followed by a vendor XYZ model. So if you need more than what the first model above provides, you will need to get a consortium of vendors together to design a new model a few vendors agree on. Andrew
