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

[Jiri Pirko]

Thu, Aug 22, 2024 at 03:20:20PM CEST, gakula@xxxxxxxxxxx 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.