Received-SPF: pass (google.com: domain of linux-kernel+bounces-187564-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Thu, 23 May 2024 15:19:30 +0200
From: Andrew Lunn <andrew@lunn.ch>
To: Larry Chiu <larry.chiu@realtek.com>
Cc: Justin Lai <justinlai0215@realtek.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"edumazet@google.com" <edumazet@google.com>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"jiri@resnulli.us" <jiri@resnulli.us>,
	"horms@kernel.org" <horms@kernel.org>,
	Ping-Ke Shih <pkshih@realtek.com>
Subject: Re: [PATCH net-next v19 01/13] rtase: Add pci table supported in
 this module
Message-ID: <8c6ad434-ba3a-4acf-9b10-9dff8efd4ee5@lunn.ch>
References: <20240517075302.7653-1-justinlai0215@realtek.com>
 <20240517075302.7653-2-justinlai0215@realtek.com>
 <d840e007-c819-42df-bc71-536328d4f5d7@lunn.ch>
 <e5d7a77511f746bdb0b38b6174ef5de4@realtek.com>
 <97e30c5f-1656-46d0-b06c-3607a90ec96f@lunn.ch>
 <f9133a36bbae41138c3080f8f6282bfd@realtek.com>
 <7aab03ba-d8ed-4c9c-8bfd-b2bbed0a922d@lunn.ch>
 <5270598ca3fc4712ac46600fcc844d73@realtek.com>
 <0ec88b78-a9d3-4934-96cb-083b2abf7e2b@lunn.ch>
 <48072595c9c344fea9c268fd81e4d06e@realtek.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <48072595c9c344fea9c268fd81e4d06e@realtek.com>

On Thu, May 23, 2024 at 06:29:55AM +0000, Larry Chiu wrote:
> 
> > > Thank you very much for your clear reply.
> > >
> > > As I mentioned, it works like a NIC connected to an Ethernet Switch, not a
> > > Management port.
> > > The packets from this GMAC are routed according to switch rules such as
> > > ACL, L2, .... and it does not control packet forwarding through any special
> > > header or descriptor. In this case, we have our switch tool which is used
> > > for provisioning these rules in advance. Once the switch boots up, the
> > > rules will be configured into the switch after the initialization. With this
> > > driver and the provisioning by our switch tool, it can make switch forward
> > > the frame as what you want. So it's not a DSA like device.
> > 
> > How does spanning tree work? You need to send bridge PDUs out specific
> > ports. Or do you not support STP and your network must never have
> > loops otherwise it dies in a broadcast storm? That does not sound very
> > reliable.
> > 
> > There are other protocols which require sending packets out specific
> > ports. Are they simply not supported?
> > 
> This port is not a CPU port, nor a management port, and therefore does not 
> manage any protocols of the switch. These protocols are implemented by the
> CPU inside the Ethernet switch core.

So STP is on the switch CPU. Linux will run PTP as a leaf node, and
rely on the switch also running PTP to manage PTP between the upstream
port and the downstream port towards linux. IGMP snooping runs on the
switch, and needs to listen to IGMP joins Linux sends out, etc.

Do you have Linux running on the switch CPU? So you can reuse all the
existing networking code and applications like ptp4l, or have the
re-invented it all?

> This driver just service the transmit/receive packets for one port in the RTL90xx
> with PCIe interface. Other programs that the switch needs to execute are
> managed by the CPU inside the switch core.

So you are following the 40 year old model, a cable to an external
device. Just be aware, it is an external device. Your interface to it
is SNMP, telnet, http. It is very unlikely a kernel driver will be
allowed to communicate with the switch.

	Andrew