On Tue, Aug 28, 2018 at 6:54 PM Sunil Kovvuri [off-list ref] wrote:

On Tue, Aug 28, 2018 at 5:53 PM Arnd Bergmann [off-list ref] wrote:

quoted

On Tue, Aug 28, 2018 at 12:57 PM [off-list ref] wrote:

quoted

From: Sunil Goutham <sgoutham@marvell.com>

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.

quoted

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.

quoted

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.

quoted

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.