Hello Andrew, > -----Original Message----- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Monday, April 2, 2018 4:45 PM > To: Ioana Ciornei <ioana.cior...@nxp.com> > Cc: Arnd Bergmann <a...@arndb.de>; gregkh > <gre...@linuxfoundation.org>; Laurentiu Tudor > <laurentiu.tu...@nxp.com>; Linux Kernel Mailing List <linux- > ker...@vger.kernel.org>; Stuart Yoder <stuyo...@gmail.com>; Ruxandra > Ioana Ciocoi Radulescu <ruxandra.radule...@nxp.com>; Razvan Stefanescu > <razvan.stefane...@nxp.com>; Roy Pledge <roy.ple...@nxp.com>; > Networking <netdev@vger.kernel.org> > Subject: Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support > > Hi Ioana > > > The commands listed above are for creating/destroying DPAA2 objects > > in Management Complex and not for runtime configuration where > > standard userspace tools are used. > > Please can you explain why this is not just plumbing inside a > switchdev driver? > > The hardware has a number of physical ports. So on probe, i would > expect it to create a DPMAC, DPNI, and DPIO for each port, and a linux > netdev. From then on, standard tools are all that are needed. The > switchdev driver can create a l2 switch object when the user uses the > ip link add name br0 type bridge. It can then connect the switch > object to the DPNI when the user adds an interface to the switch, etc. >
I'll chime in as you mentioned switchdev driver. DPAA2 offers several object-based abstractions for modeling network related devices (interfaces, L2 Ethernet switch) or accelerators (DPSECI - crypto and DPDCEI - compression), the latter not up-streamed yet. They are modeled using various low-level resources (e.g. queues, classification tables, physical ports) and have multiple configuration and interconnectivity options, managed by the Management Complex. Resources are limited and they are only used when needed by the objects, to accommodate more configurations and usage scenarios. Some of the objects have a 1-to-1 correspondence to physical resources (e.g. DPMACs to physical ports), while others (like DPNIs and DPSW) can be seen as a collection of the mentioned resources. The types and number of such objects are not predetermined. When the board boots up, none of them exist yet. Restool allows a user to define the system topology, by providing a way to dynamically create, destroy and interconnect these objects. After an object is created, it will be presented on the fsl-mc bus. A driver is loaded to implement the required kernel interfaces specific to that object type. Kernel can boot and afterwards the DPAA2 objects are added, as the user requires. As you mentioned DPMACs: objects of this type can be connected only to a DPNI (a network interface like object) or to a DPSW (L2 ethernet switch) port. Likewise, a DPNI can have only one connection (to a DPMAC, a DPSW port or another DPNI object). Here's several examples of valid connection types: * DPMAC <----> DPNI (standard network i/f corresponding to a physical port) * DPMAC <----> DPSW (physical port in a switch) * DPNI <----> DPSW (virtual network interface connected to a switch port) * DPNI <----> DPNI In the latter case, the two DPNIs will not be connected to any physical port, but can be used as a point-to-point connection between two virtual machines for instance. So, it is not possible to connect a DPNI to a DPSW after it was connected to a DPMAC. The DPNI-DPMAC pair would have to be disconnected and DPMAC will be reconnected to the switch. DPNI interface that is no longer connected to a DPMAC will be destroyed and any new addition/deletion of a DPNI/DPMAC interface to the switch port will trigger the entire switch re-configuration. Best regards, Razvan Stefanescu
