On Fri, Oct 26, 2018 at 6:24 PM Arnd Bergmann [off-list ref] wrote:

On 10/23/18, David Miller [off-list ref] wrote:

quoted

From: sunil.kovvuri@gmail.com
Date: Mon, 22 Oct 2018 23:25:47 +0530

quoted

From: Sunil Goutham <sgoutham@marvell.com>

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

As of now it's only mbox based configuration that is supported.

Thanks,
Sunil.