Re: [PATCH 00/15] soc: octeontx2: Add RVU admin function driver

[Sunil Kovvuri]

On Tue, Aug 28, 2018 at 6:54 PM Sunil Kovvuri <sunil.kovvuri@xxxxxxxxx> wrote:
>
> 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

Hi Arnd,

I hope i have answered your queries.
Let us know if you have any more queries or feedback w.r.t to a
individual patch or the patchset on the whole.

Thanks,
Sunil.