On Fri, Sep 28, 2018 at 1:57 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > 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. 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
