linux-kernel - Re: [RFC PATCH net-next 01/28] docs: networking: ti: add driver doc for CPSW Proxy Client

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-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 21 May 2024 15:07:40 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Siddharth Vadapalli <s-vadapalli@...com>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com, corbet@....net, rogerq@...nel.org,
	danishanwar@...com, vladimir.oltean@....com, netdev@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, vigneshr@...com,
	misael.lopez@...com, srk@...com
Subject: Re: [RFC PATCH net-next 01/28] docs: networking: ti: add driver doc
 for CPSW Proxy Client

> Andrew,
> 
> Thank you for reviewing the patch and sharing your feedback. While I
> have come across other Switch Designs / Architecture, I am yet to go
> through the one you have mentioned below. I will go through it in detail
> and will follow up with my understanding in a future reply. This reply
> is intended to be an acknowledgment that I have read your feedback.
> I also wanted to clarify the use-case which this series targets. The
> requirements of the use-case are:
> 1. Independent Ethernet Switch functionality: Switch operation and
> configuration when Linux is not functional (Fast startup, Low Power
> Mode, Safety use-cases).
> 2. Dynamic Ethernet Switch configuration changes performed based on the
> applications which run on various cores.

Please make sure these requirements are clearly stated in the design.

The support for switches in Linux has initially come from big data
centre switches, and smaller SOHO switches you found in OpenWRT class
devices. The switchdev model has worked well so far for these use
cases. However, i do understand you have additional requirements.

Ideally we want to extend the existing model to support additional use
cases, not create a second parallel model. And we want a vendor
agnostic extensions of the switchdev model, something which all
automotive vendors can use, and non-automotive systems which have a
similar architecture.

	Andrew