Re: [net-next PATCH v11 00/11] Introduce RVU representors

Thu, Aug 22, 2024 at 03:20:20PM CEST, gakula@marvell.com wrote:

This series adds representor support for each rvu devices.
When switchdev mode is enabled, representor netdev is registered
for each rvu device. In implementation of representor model, 
one NIX HW LF with multiple SQ and RQ is reserved, where each
RQ and SQ of the LF are mapped to a representor. A loopback channel
is reserved to support packet path between representors and VFs.
CN10K silicon supports 2 types of MACs, RPM and SDP. This
patch set adds representor support for both RPM and SDP MAC
interfaces.

- Patch 1: Refactors and exports the shared service functions.
- Patch 2: Implements basic representor driver.
- Patch 3: Add devlink support to create representor netdevs that
 can be used to manage VFs.
- Patch 4: Implements basec netdev_ndo_ops.
- Patch 5: Installs tcam rules to route packets between representor and
   VFs.
- Patch 6: Enables fetching VF stats via representor interface
- Patch 7: Adds support to sync link state between representors and VFs .
- Patch 8: Enables configuring VF MTU via representor netdevs.
- Patch 9: Add representors for sdp MAC.
- Patch 10: Add devlink port support.

What is the fastpath? Where do you offload any configuration that
actually ensures VF<->physical_port and VF<->VF traffic? There should be
some bridge/tc/route offload.

Or, what I fear, do you use some implicit mac-based steering? If yes,
you should not. In switchdev mode, if user does not configure
representors to forward packets, there is no packet forwarding.