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

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:   Mon, 2 Apr 2018 13:24:58 +0000
From:   Ioana Ciornei <ioana.ciornei@....com>
To:     Andrew Lunn <andrew@...n.ch>, Arnd Bergmann <arnd@...db.de>
CC:     gregkh <gregkh@...uxfoundation.org>,
        Laurentiu Tudor <laurentiu.tudor@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Stuart Yoder <stuyoder@...il.com>,
        Ruxandra Ioana Ciocoi Radulescu <ruxandra.radulescu@....com>,
        Razvan Stefanescu <razvan.stefanescu@....com>,
        Roy Pledge <roy.pledge@....com>,
        Networking <netdev@...r.kernel.org>
Subject: RE: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support

> 
> > I'm still not convinced either way (high-level or low-level
> > interface), but I think this needs to be discussed with the networking
> > maintainers. Given the examples on the github page you linked to, the
> > high-level user space commands based on these ioctls
> >
> >    ls-addni   # adds a network interface
> >    ls-addmux  # adds a dpdmux
> >    ls-addsw   # adds an l2switch
> >    ls-listmac # lists MACs and their connections
> >    ls-listni  # lists network interfaces and their connections
> >
> > and I see that you also support the switchdev interface in
> > drivers/staging/fsl-dpaa2, which I think does some of the same things,
> > presumably by implementing the switchdev API using fsl_mc_command
> > low-level interfaces in the kernel.
> 
> Hi Arnd
> 
> I agree that switchdev and devlink should be the correct way to handle this. The
> low level plumbing of the hardware should all be hidden. There should not be
> any user space commands needed other than the usual network configuration
> tools and devlink.
> 

Hi,

The commands listed above are for creating/destroying DPAA2 objects in Management Complex and not for runtime configuration where standard userspace tools are used.
Restool is responsible for creating objects in Management complex and this process can be seen as the equivalent of hotplugging a peripheral rather than configuring it, thus there is no standard userspace tool to handle that.

* The Management Complex is configured to create a specific set of DPAA2 objects dynamically through Restool (by sending create commands) or statically, at boot time, through a configuration file (Data Path Layout file)
* The objects are then probed and configured by the corresponding drivers
* The objects are controlled at runtime by the user via standard tools (e.g. ethtool for network interfaces).

I hope this gives a better understanding on the DPAA2 hardware and software architecture. The fsl-mc bus documentation gives more details on this: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/tree/Documentation/networking/dpaa2/overview.rst?h=staging-next

Ioana