RE: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support

[Razvan Stefanescu]

Hello Andrew,

> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@xxxxxxx]
> Sent: Monday, April 2, 2018 4:45 PM
> To: Ioana Ciornei <ioana.ciornei@xxxxxxx>
> Cc: Arnd Bergmann <arnd@xxxxxxxx>; gregkh
> <gregkh@xxxxxxxxxxxxxxxxxxx>; Laurentiu Tudor
> <laurentiu.tudor@xxxxxxx>; Linux Kernel Mailing List <linux-
> kernel@xxxxxxxxxxxxxxx>; Stuart Yoder <stuyoder@xxxxxxxxx>; Ruxandra
> Ioana Ciocoi Radulescu <ruxandra.radulescu@xxxxxxx>; Razvan Stefanescu
> <razvan.stefanescu@xxxxxxx>; Roy Pledge <roy.pledge@xxxxxxx>;
> Networking <netdev@xxxxxxxxxxxxxxx>
> 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