On Tue, Aug 28, 2018 at 5:53 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Tue, Aug 28, 2018 at 12:57 PM <sunil.kovvuri@xxxxxxxxx> wrote: > > > > From: Sunil Goutham <sgoutham@xxxxxxxxxxx> > > > > Resource virtualization unit (RVU) on Marvell's OcteonTX2 SOC supports > > multiple PCIe SRIOV physical functions (PFs) and virtual functions (VFs). > > PF0 is called administrative / admin function (AF) and has privilege access > > to registers to provision different RVU functional blocks to each of > > PF/VF. > > > > This admin function (AF) driver acts as a configuration / administrative > > software which provisions functional blocks to a PF/VF on demand for them > > to work as one of the following > > - A basic network controller (i.e NIC). > > - NIC with packet filtering, shaping and scheduling capabilities. > > - A crypto device. > > - A combination of above etc. > > > > PF/VFs communicate with admin function via a shared memory region. > > 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 driver which provides information about physcial network > > interfaces which AF processes and forwards required info to > > PF/VF drivers. > > > > This is the first set of patches out of 70 odd patches. > > > > Note: This driver neither receives any data nor processes it i.e no I/O, > > just does the hardware configuration. > > Hi Sunil, > > Thanks for posting this first series, I'm glad we're seeing support for this > chip family making some progress. Thanks. > > My feeling overall is that we need a review from the network driver > folks more than the arm-soc team etc, and that maybe the driver > as a whole should go into drivers/net/ethernet. This driver doesn't handle any network IO and moreever this driver has to handle configuration requests from crypto driver as well. There will be separate network and crypto drivers which will be upstreamed into drivers/net/ethernet and drivers/crypto. And in future silicons there will be different types of functional blocks which will be added into this resource virtualization unit (RVU). Hence i thought this driver is not a right fit in drivers/net/ethernet. > > We support some couple of similar hardware already that has > both support for virtual functions and for crypto offload, including > the Chelsio cxgb4, Mellanox mlx5, NXP DPAA and probably others, I agree, but i guess that is done to support inline crypto. Here this driver has to handle requests from normal crypto driver (drivers/crypto) as well. > and we need to ensure that the exposed interfaces are all > compatible, and that you use the correct subsystems and > in-kernel abstractions for thing that are common. > > Arnd
