On Wed, 14 Apr 2021 11:05:50 -0700 Saeed Mahameed wrote:
> From: Parav Pandit <pa...@nvidia.com>
> 
> Currently each packet inserted in eswitch is tagged with a internal
> metadata to indicate source vport. Metadata tagging is not always
> needed. Metadata insertion is needed for multi-port RoCE, failover
> between representors and stacked devices. In many other cases,
> metadata enablement is not needed.
> 
> Metadata insertion slows down the packet processing rate of the E-switch
> when it is in switchdev mode.
> 
> Below table show performance gain with metadata disabled for VXLAN
> offload rules in both SMFS and DMFS steering mode on ConnectX-5 device.
> 
> ----------------------------------------------
> | steering | metadata | pkt size | rx pps    |
> | mode     |          |          | (million) |
> ----------------------------------------------
> | smfs     | disabled | 128Bytes | 42        |
> ----------------------------------------------
> | smfs     | enabled  | 128Bytes | 36        |
> ----------------------------------------------
> | dmfs     | disabled | 128Bytes | 42        |
> ----------------------------------------------
> | dmfs     | enabled  | 128Bytes | 36        |
> ----------------------------------------------
> 
> Hence, allow user to disable metadata using driver specific devlink
> parameter. Metadata setting of the eswitch is applicable only for the
> switchdev mode.
> 
> Example to show and disable metadata before changing eswitch mode:
> $ devlink dev param show pci/0000:06:00.0 name esw_port_metadata
> pci/0000:06:00.0:
>   name esw_port_metadata type driver-specific
>     values:
>       cmode runtime value true
> 
> $ devlink dev param set pci/0000:06:00.0 \
>         name esw_port_metadata value false cmode runtime
> 
> $ devlink dev eswitch set pci/0000:06:00.0 mode switchdev
> 
> Signed-off-by: Parav Pandit <pa...@nvidia.com>
> Reviewed-by: Roi Dayan <r...@nvidia.com>
> Reviewed-by: Vu Pham <vuhu...@nvidia.com>
> Signed-off-by: Saeed Mahameed <sae...@nvidia.com>

Acked-by: Jakub Kicinski <k...@kernel.org>

Reply via email to