Yael Chemla via dev <ovs-dev@openvswitch.org> writes:

> Commit aee4f9aec ("netdev-offload-tc: Match against tunnel flags
> if supported") added support to match against 'csum' and 'df' tunnel
> flags in TC, assuming they’re only set when actually needed. But
> the code in tnl_wc_init() always sets these flags by default,
> without checking if HW offload is enabled or if the flow explicitly
> requests them. This breaks HW offload, since mlx5 (and other NICs)
> do not support offloading when these flags are set.
>
> To work around this, users are currently have to add the following
> options to their flows "options:df_default=false options:csum=false".
> This patch helps by adjusting the wildcard mask according to actual
> tunnel config. If 'csum' or 'df' are disabled, the mask will no
> longer include them.
>
> Note that the decision to match these flags depends on
> `enc_flags_support`, which is probed once via
> `probe_enc_flags_support()`. In most cases, this probe is performed
> against the ovs-system device with `tc_policy=SKIP_HW`, which causes
> the probe to succeed regardless of whether the underlying hardware
> can actually offload these flags. Therefore, relying solely on
> `enc_flags_support` is insufficient and can result in incorrect
> behavior. This patch works around the issue by ensuring that even
> if support is globally enabled, the wildcard mask reflects the actual
> per-port tunnel configuration to avoid unnecessary matches that would
> break hardware offload.
>
> Reviewed-by: Jianbo Liu <jian...@nvidia.com>
> Signed-off-by: Yael Chemla <yche...@nvidia.com>
> ---

Hi Yael,

>  ofproto/ofproto-dpif-xlate.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
> index 2c8197fb7..ea9ca903f 100644
> --- a/ofproto/ofproto-dpif-xlate.c
> +++ b/ofproto/ofproto-dpif-xlate.c
> @@ -8433,6 +8433,18 @@ xlate_actions(struct xlate_in *xin, struct
> xlate_out *xout)

Most likely this part of the patch got corrupted.  Not sure where in
your send operations it would have modified this, but I would guess this
is causing a context issue.

>          ctx.xin->xport_uuid = in_port->uuid;
>      }
> +    if (in_port && in_port->is_tunnel) {
> +        const struct netdev_tunnel_config *tnl_cfg;
> +
> +        tnl_cfg = netdev_get_tunnel_config(in_port->netdev);
> +        if (!tnl_cfg->dont_fragment) {
> +            ctx.wc->masks.tunnel.flags &= ~FLOW_TNL_F_DONT_FRAGMENT;
> +        }
> +        if (tnl_cfg->csum == NETDEV_TNL_CSUM_DISABLED) {
> +            ctx.wc->masks.tunnel.flags &= ~FLOW_TNL_F_CSUM;
> +        }
> +    }
> +
>      if (flow->packet_type != htonl(PT_ETH) && in_port &&
>          in_port->pt_mode == NETDEV_PT_LEGACY_L3 && ctx.table_id == 0) {
>          /* Add dummy Ethernet header to non-L2 packet if it's coming from a

_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to