netdev - Re: [PATCH 00/15] octeontx2-af: Add RVU Admin Function driver

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: <CA+sq2CdsUsmkxxfEpy6vKAmaOWfUDX9eR9r-DRXcY3u9DG4FMw@mail.gmail.com>
Date:   Fri, 28 Sep 2018 15:05:23 +0530
From:   Sunil Kovvuri <sunil.kovvuri@...il.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Linux Netdev List <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>, linux-soc@...r.kernel.org,
        Sunil Goutham <sgoutham@...vell.com>
Subject: Re: [PATCH 00/15] octeontx2-af: Add RVU Admin Function driver

On Fri, Sep 28, 2018 at 1:57 PM Arnd Bergmann <arnd@...db.de> wrote:
>
> On Fri, Sep 28, 2018 at 8:08 AM <sunil.kovvuri@...il.com> wrote:
> >
> > From: Sunil Goutham <sgoutham@...vell.com>
> >
> > Resource virtualization unit (RVU) on Marvell's OcteonTX2 SOC maps HW
> > resources from the network, crypto and other functional blocks into
> > PCI-compatible physical and virtual functions. Each functional block
> > again has multiple local functions (LFs) for provisioning to PCI devices.
> > RVU supports multiple PCIe SRIOV physical functions (PFs) and virtual
> > functions (VFs). PF0 is called the administrative / admin function (AF)
> > and has privileges to provision RVU functional block's LFs to each of the
> > PF/VF.
> >
> > RVU managed networking functional blocks
> >  - Network pool allocator (NPA)
> >  - Network interface controller (NIX)
> >  - Network parser CAM (NPC)
> >  - Schedule/Synchronize/Order unit (SSO)
> >
> > RVU managed non-networking functional blocks
> >  - Crypto accelerator (CPT)
> >  - Scheduled timers unit (TIM)
> >  - Schedule/Synchronize/Order unit (SSO)
> >    Used for both networking and non networking usecases
> >  - Compression (upcoming in future variants of the silicons)
> >
> > Resource provisioning examples
> >  - A PF/VF with NIX-LF & NPA-LF resources works as a pure network device
> >  - A PF/VF with CPT-LF resource works as a pure cyrpto offload device.
> >
> > This admin function driver neither receives any data nor processes it i.e
> > no I/O, a configuration only driver.
> >
> > PF/VFs communicates with AF via a shared memory region (mailbox). Upon
> > receiving requests from PF/VF, AF does resource provisioning and other
> > HW configuration. AF is always attached to host, but PF/VFs may be used
> > by host kernel itself, or attached to VMs or to userspace applications
> > like DPDK etc. So AF has to handle provisioning/configuration requests
> > sent by any device from any domain.
> >
> > This patch series adds logic for the following
> >  - RVU AF driver with functional blocks provisioning support.
> >  - Mailbox infrastructure for communication between AF and PFs.
> >  - CGX (MAC controller) driver which communicates with firmware for
> >    managing  physical ethernet interfaces. AF collects info from this
> >    driver and forwards the same to the PF/VFs uaing these interfaces.
> >
> > This is the first set of patches out of 80+ patches.
>
> Hi Sunil,
>
> This looks good overall, thanks for moving it to drivers/net
> as I suggested. I found two more minor remaining issues here,
> it should not be a problem to change the code accordingly.
>
> One thing I was missing here is a revision history for the patch
> series, it would have been helpful to get a list of things you have
> changed compared to the previous submission, what triggered
> those changes, and which issues (if any) are still remaining.
> Best add the full revision history in the next (hopefully final)
> round for these patches, and use 'git format-patch --reroll-count'
> to add the patchset revision number.

Not much changes done to the patches since the v3 patchset i submitted
on drivers/soc. But yes, i will add the old revision history while re-submitting
patches after addressing your suggestions.

>
> I assume that the next set of patches will be more controversial
> as you get to the point that adds the user interface. I have
> not looked at those patches yet, so it may just be fine, assuming
> all the configuration is done using devlink. Please keep me
> on Cc for the future series, even if I don't participate in those
> reviews as much.

Sure I will keep you in CC.

>
> Thanks,
>
>       Arnd