| Message ID | 1535453838-12154-1-git-send-email-sunil.kovvuri@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | soc: octeontx2: Add RVU admin function driver | expand |
On Tue, Aug 28, 2018 at 12:57 PM <sunil.kovvuri@gmail.com> wrote: > > 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. 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. 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, 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
On Tue, Aug 28, 2018 at 5:53 PM Arnd Bergmann <arnd@arndb.de> wrote: > > On Tue, Aug 28, 2018 at 12:57 PM <sunil.kovvuri@gmail.com> wrote: > > > > 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. > > 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
On Tue, Aug 28, 2018 at 6:54 PM Sunil Kovvuri <sunil.kovvuri@gmail.com> wrote: > > On Tue, Aug 28, 2018 at 5:53 PM Arnd Bergmann <arnd@arndb.de> wrote: > > > > On Tue, Aug 28, 2018 at 12:57 PM <sunil.kovvuri@gmail.com> wrote: > > > > > > 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. > > > > > 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.
> > > 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. Hi Sunil Do you have a git branch for everything? I would like to look at the actual Ethernet driver, and the full API this driver exports to other drivers. I think there real question here is, do you have split between this driver and the actual device drivers in the right place? For me, link up/down detection should be in the Ethernet driver, since it is not shared with the crypto driver. Thanks Andrew
On Thu, Aug 30, 2018 at 6:57 PM Andrew Lunn <andrew@lunn.ch> wrote: > > > > > 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. > > Hi Sunil > > Do you have a git branch for everything? I would like to look at the > actual Ethernet driver, and the full API this driver exports to other > drivers. Hi Andrew, I have pushed all patches into a github repo for your reference. These are not the final patches, i still need to do some minor changes before submitting (i mean otherthan the ones i already submitted). AF driver & CGX drivers: https://github.com/sunilkovvuri/rvu_drivers/tree/master/drivers/soc/marvell/octeontx2 Ethernet drivers PF and VF https://github.com/sunilkovvuri/rvu_drivers/tree/master/drivers/net/ethernet/marvell/octeontx2 Info exported/shared by AF driver with other drivers is # Mailbox communication APIs, message IDs, message structs e.t.c https://github.com/sunilkovvuri/rvu_drivers/blob/master/drivers/soc/marvell/octeontx2/mbox.c https://github.com/sunilkovvuri/rvu_drivers/blob/master/drivers/soc/marvell/octeontx2/mbox.h # Other structs and APIs https://github.com/sunilkovvuri/rvu_drivers/blob/master/drivers/soc/marvell/octeontx2/common.h https://github.com/sunilkovvuri/rvu_drivers/blob/master/drivers/soc/marvell/octeontx2/rvu_struct.h > > I think there real question here is, do you have split between this > driver and the actual device drivers in the right place? For me, link > up/down detection should be in the Ethernet driver, since it is not > shared with the crypto driver. > As mentioned in the patch '[PATCH 13/15] soc: octeontx2: Add support for CGX link management', link up/down is detected by firmware. And firmware triggers a IRQ to CGX driver, which then takes the new status and sends a update to ethernet driver via a mailbox communication. Ethernet driver detects the link change and does the necessary stuff. https://github.com/sunilkovvuri/rvu_drivers/blob/master/drivers/net/ethernet/marvell/octeontx2/otx2_pf.c#L116 > Thanks > Andrew
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. Aleksey Makarov (2): soc: octeontx2: Add mailbox support infra soc: octeontx2: Convert mbox msg id check to a macro Geetha sowjanya (1): soc: octeontx2: Reconfig MSIX base with IOVA Linu Cherian (3): soc: octeontx2: Set RVU PFs to CGX LMACs mapping soc: octeontx2: Add support for CGX link management soc: octeontx2: Register for CGX lmac events Sunil Goutham (9): soc: octeontx2: Add Marvell OcteonTX2 RVU AF driver soc: octeontx2: Reset all RVU blocks soc: octeontx2: Gather RVU blocks HW info soc: octeontx2: Add mailbox IRQ and msg handlers soc: octeontx2: Scan blocks for LFs provisioned to PF/VF soc: octeontx2: Add RVU block LF provisioning support soc: octeontx2: Configure block LF's MSIX vector offset soc: octeontx2: Add Marvell OcteonTX2 CGX driver MAINTAINERS: Add entry for Marvell OcteonTX2 Admin Function driver MAINTAINERS | 10 + drivers/soc/Kconfig | 1 + drivers/soc/Makefile | 1 + drivers/soc/marvell/Kconfig | 23 + drivers/soc/marvell/Makefile | 2 + drivers/soc/marvell/octeontx2/Makefile | 10 + drivers/soc/marvell/octeontx2/cgx.c | 529 +++++++++ drivers/soc/marvell/octeontx2/cgx.h | 63 ++ drivers/soc/marvell/octeontx2/cgx_fw_if.h | 225 ++++ drivers/soc/marvell/octeontx2/mbox.c | 300 +++++ drivers/soc/marvell/octeontx2/mbox.h | 211 ++++ drivers/soc/marvell/octeontx2/rvu.c | 1625 ++++++++++++++++++++++++++++ drivers/soc/marvell/octeontx2/rvu.h | 158 +++ drivers/soc/marvell/octeontx2/rvu_cgx.c | 194 ++++ drivers/soc/marvell/octeontx2/rvu_reg.h | 442 ++++++++ drivers/soc/marvell/octeontx2/rvu_struct.h | 78 ++ 16 files changed, 3872 insertions(+) create mode 100644 drivers/soc/marvell/Kconfig create mode 100644 drivers/soc/marvell/Makefile create mode 100644 drivers/soc/marvell/octeontx2/Makefile create mode 100644 drivers/soc/marvell/octeontx2/cgx.c create mode 100644 drivers/soc/marvell/octeontx2/cgx.h create mode 100644 drivers/soc/marvell/octeontx2/cgx_fw_if.h create mode 100644 drivers/soc/marvell/octeontx2/mbox.c create mode 100644 drivers/soc/marvell/octeontx2/mbox.h create mode 100644 drivers/soc/marvell/octeontx2/rvu.c create mode 100644 drivers/soc/marvell/octeontx2/rvu.h create mode 100644 drivers/soc/marvell/octeontx2/rvu_cgx.c create mode 100644 drivers/soc/marvell/octeontx2/rvu_reg.h create mode 100644 drivers/soc/marvell/octeontx2/rvu_struct.h