On Fri, Sep 28, 2018 at 8:08 AM <sunil.kovvuri@xxxxxxxxx> wrote:
>
> From: Sunil Goutham <sgoutham@xxxxxxxxxxx>
>
> 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.
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.
Thanks,
Arnd
