On 10/23/18, David Miller <davem@xxxxxxxxxxxxx> wrote: > From: sunil.kovvuri@xxxxxxxxx > Date: Mon, 22 Oct 2018 23:25:47 +0530 > >> From: Sunil Goutham <sgoutham@xxxxxxxxxxx> >> >> This patchset is a continuation to earlier submitted two patch >> series to add a new driver for Marvell's OcteonTX2 SOC's >> Resource virtualization unit (RVU) admin function driver. >> >> 1. octeontx2-af: Add RVU Admin Function driver >> https://www.spinics.net/lists/netdev/msg528272.html >> 2. octeontx2-af: NPA and NIX blocks initialization >> https://www.spinics.net/lists/netdev/msg529163.html >> >> This patch series adds more NIX block configuration logic >> and additionally adds NPC block parser profile configuration. >> In brief below is what this series adds. >> NIX block: >> - Support for PF/VF to allocate/free transmit scheduler queues, >> maintenance and their configuration. >> - Adds support for packet replication lists, only broadcast >> packets is covered for now. >> - Defines few RSS flow algorithms for HW to distribute packets. >> This is not the hash algorithsm (i.e toeplitz or crc32), here SW >> defines what fields in packet should HW take and calculate the hash. >> - Support for PF/VF to configure VTAG strip and capture capabilities. >> - Reset NIXLF statastics. >> >> NPC block: >> This block has multiple parser engines which support packet parsing >> at multiple layers and generates a parse result which is further used >> to generate a key. Based on packet field offsets in the key, SW can >> install packet forwarding rules. >> This patch series adds >> - Initial parser profile to be programmed into parser engines. >> - Default forwarding rules to forward packets to different logical >> interfaces having a NIXLF attached. >> - Support for promiscuous and multicast modes. >> >> Changes from v1: >> 1 Fixed kernel build failure when compiled with BIG_ENDIAN enabled. >> - Reported by Kbuild test robot >> 2 Fixed a warning observed when kernel is built with >> -Wunused-but-set-variable > > Series applied. I see this has been applied, but I'd still like to understand better how the configuration interface is expected to work once the driver is complete. In particular, so far the interfaces all assume that configuration is done through the mailbox between PCI devices, which could be done from a virtual machine kernel with access to PCI, or through the use of VFIO from a user application. Is that the only method of configuring it that you support, or will there also be a devlink based interface or something like that to configure the aspects of a virtual device that should not be accessible to the VF itself? Arnd
