netdev - RE: [EXT] Re: [V2 net-next] net: mvpp2: Add reserved port private flag configuration

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]

Message-ID: <CO6PR18MB38733E25F6B3194D4858147BB06B9@CO6PR18MB3873.namprd18.prod.outlook.com>
Date:   Tue, 16 Mar 2021 15:28:51 +0000
From:   Stefan Chulski <stefanc@...vell.com>
To:     Andrew Lunn <andrew@...n.ch>, "kuba@...nel.org" <kuba@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "thomas.petazzoni@...tlin.com" <thomas.petazzoni@...tlin.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        Nadav Haklai <nadavh@...vell.com>,
        Yan Markman <ymarkman@...vell.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "mw@...ihalf.com" <mw@...ihalf.com>,
        "rmk+kernel@...linux.org.uk" <rmk+kernel@...linux.org.uk>,
        "atenart@...nel.org" <atenart@...nel.org>,
        "rabeeh@...id-run.com" <rabeeh@...id-run.com>
Subject: RE: [EXT] Re: [V2 net-next] net: mvpp2: Add reserved port private
 flag configuration

> Hi Stefan
> 
> Thanks for the strings change. Looks a lot better.
> 
> Now i took a look at the bigger picture.
> 
> > According to Armada SoC architecture and design, all the PPv2 ports
> > which are populated on the same communication processor silicon die
> > (CP11x) share the same Classifier and Parser engines.
> >
> > Armada is an embedded platform and therefore there is a need to
> > reserve some of the PPv2 ports for different use cases.
> >
> > For example, a port can be reserved for a CM3 CPU running FreeRTOS for
> > management purposes

Hi Andrew and Jakub,

There are multiple reasons why we must let the kernel initialize and manage the reserved port:
1. According to pp2 hardware design, all classifier and parser configuration access are indirect. In order to prevent race conditions, it needs to be configured by single entity. 
2. CM3 code has very small footprint requirement, we cannot implement the complete Serdes and PHY infrastructure that kernel provides as part of CM3 application. Therefore I would like to continue relying on kernel configuration for that.
3. In some cases we need to dynamically switch the port "user" between CM3 and kernel. So I would like to preserve this functionality.

> So the CM3 CPU has its own driver for this hardware? It seems like we should
> not even instantiate the Linux driver for this port. Does the
> CM3 have its own DT blob? I think the better solution is that the Armada DT
> for the board does not list the port, and the DT for the CM3 does. Linux
> never sees the port, since Linux should not be using it.
> 
> > or by user-space data plane application.
> 
> You mean XDP/AF_XDP? I don't see any other XDP capable drivers having a
> flag like this. If this was required, i would expect it to be a common properly,
> not driver private.

No XDP doesn't require this. One of the use cases of the port reservation feature is the Marvell User Space SDK (MUSDK) which its latest code is publicly available here:
https://github.com/MarvellEmbeddedProcessors/musdk-marvell
You can find example use case for this application here:
http://wiki.macchiatobin.net/tiki-index.php?page=MUSDK+Introduction

Stefan.