From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 433EEA00BE for ; Mon, 14 Mar 2022 08:55:50 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 14A7540DDD; Mon, 14 Mar 2022 08:55:50 +0100 (CET) Received: from smtp-relay-internal-0.canonical.com (smtp-relay-internal-0.canonical.com [185.125.188.122]) by mails.dpdk.org (Postfix) with ESMTP id BFC8740DDD for ; Mon, 14 Mar 2022 08:55:48 +0100 (CET) Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 278723F499 for ; Mon, 14 Mar 2022 07:55:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1647244548; bh=pcukz+AiEizMkMbMYMaO2yJoSDRKtyIcePZpG3K+oHk=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=NMBtpXKdUX9+2dLZSA2ui+3LK1B4TmmKjK6ipcNddZA+h5O3NGMV1gkArukegiRsz gsI9/nHpX39Z0yqx/wRhYO/axqeeGQMf8MJica4J94W9OVJCIxGgcYN7mYqpTuSdbx Il0GyR+tOlvLAWWoz8HVTGYHWxirqw7evBj7t/P4DDwq0nEOzV6LWV8rjsq2htPiCS WTYxfsBbBWqoQr7PVN6K8rwd8FrA8jyojHqMybNbyEQeJy7KePMNyTOkOk4QVS1qoG LcIFFFdGfCvAZ1FWvJ5rkCycF8mpPgfCxEoT3nEJ4t4sxo4txLJeKAtFyc2jCC61jQ oDkT290CPh8Dw== Received: by mail-qk1-f198.google.com with SMTP id z10-20020a05620a08ca00b0067d341e82edso11082718qkz.17 for ; Mon, 14 Mar 2022 00:55:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pcukz+AiEizMkMbMYMaO2yJoSDRKtyIcePZpG3K+oHk=; b=NPbAtNIdFosX72qt1AtsNkVOQZJkAh13gNan4kZIK88B4MNkc9kzmF5csozd2U3NP5 2ak3/jx2KpQk/k/MXqC5emNu9YH5SJxB49Yfw+63rJjHxRTuSPlsBGNZYgCf0+GsHRc4 /cXyxHcezEKbqd5Rlbthm9kjY01PzfGaB6kDvywoUH0VsdOe7dd2rkfIvBx+TYRpya5P 8U1bqHkre/0vuTGzgRmsLoxrhGgzuUtUiGBCHZSYRJHUl/PNRrqnZ0RwQFZHM/UOtDW9 wfKAd7L+4Es5Ph+P/vb8S64l9ngVjWVx8OVgAgYlgaJZHXm1qV3GXdikUm8J8/pZBPId l05g== X-Gm-Message-State: AOAM533omq6TVMaNux+pIPeQdFIF0Nev0i+UH5bg7+6m1ATdceIxaep5 Em+Q03MyLw70Uu8NAf4+/cWNliQ819I9G/La8SpNIav8lUysdW9UHiDmBbrQvskRj8bvreMKbZp YWRx65WKNSscwTH6S6Y/6GLq56evIoQnBagHgqbbg X-Received: by 2002:a05:6214:2304:b0:438:458e:eafc with SMTP id gc4-20020a056214230400b00438458eeafcmr14061007qvb.118.1647244547246; Mon, 14 Mar 2022 00:55:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxaStnQOkW1YZIJ7PL8z7tkAgpixIjZKwNlQ9RgdgBcCqz+V9H/Mt4LVb4DMRM4PlSkmF8YUMmIcblzAcdUNoc= X-Received: by 2002:a05:6214:2304:b0:438:458e:eafc with SMTP id gc4-20020a056214230400b00438458eeafcmr14060996qvb.118.1647244547010; Mon, 14 Mar 2022 00:55:47 -0700 (PDT) MIME-Version: 1.0 References: <20220313083908.12990-1-jiaweiw@nvidia.com> In-Reply-To: <20220313083908.12990-1-jiaweiw@nvidia.com> From: Christian Ehrhardt Date: Mon, 14 Mar 2022 08:55:21 +0100 Message-ID: Subject: Re: [PATCH 19.11] net/mlx5: fix NIC egress flow mismatch in switchdev mode To: Jiawei Wang Cc: viacheslavo@nvidia.com, orika@nvidia.com, rasland@nvidia.com, Matan Azrad , Shahaf Shuler , Ori Kam , Yongseok Koh , stable@dpdk.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On Sun, Mar 13, 2022 at 9:39 AM Jiawei Wang wrote: > > [ upstream commit 6d4f1066be6cd60a95f21ef07a16a3c3676c5cd9 ] Thank you - applied to 19.11 stable > When E-Switch mode was enabled, the NIC egress flows was implicitly > appended with source vport to match on. If the metadata register C0 > was used to maintain the source vport, it was initialized to zero > on packet steering engine entry, the flow could be hit only > if source vport was zero, the register C0 of the packet was not correct > to match in the TX side, this caused egress flow misses. > > This patch: > - removes the implicit source vport match for NIC egress flow. > - rejects the NIC egress flows on the representor ports at validation. > - allows the internal NIC egress flows containing the TX_QUEUE items in > order to not impact hairpins. > > Fixes: ce777b147bf8 ("net/mlx5: fix E-Switch flow without port item") > > Signed-off-by: Jiawei Wang > Acked-by: Viacheslav Ovsiienko > Acked-by: Ori Kam > --- > doc/guides/nics/mlx5.rst | 2 ++ > drivers/net/mlx5/mlx5_flow_dv.c | 26 +++++++++++++++++++++----- > 2 files changed, 23 insertions(+), 5 deletions(-) > > diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst > index 546f0dd4c2..8f7b285271 100644 > --- a/doc/guides/nics/mlx5.rst > +++ b/doc/guides/nics/mlx5.rst > @@ -241,6 +241,8 @@ Limitations > from the reference "Clock Queue" completions, > the scheduled send timestamps should not be specified with non-zero MSB. > > +- The NIC egress flow rules on representor port are not supported. > + > Statistics > ---------- > > diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c > index dd62bbbbfb..f7e3d92045 100644 > --- a/drivers/net/mlx5/mlx5_flow_dv.c > +++ b/drivers/net/mlx5/mlx5_flow_dv.c > @@ -4833,8 +4833,10 @@ flow_dv_validate(struct rte_eth_dev *dev, const struct rte_flow_attr *attr, > return ret; > last_item = MLX5_FLOW_ITEM_TAG; > break; > - case MLX5_RTE_FLOW_ITEM_TYPE_TAG: > case MLX5_RTE_FLOW_ITEM_TYPE_TX_QUEUE: > + last_item = MLX5_FLOW_ITEM_TX_QUEUE; > + break; > + case MLX5_RTE_FLOW_ITEM_TYPE_TAG: > break; > default: > return rte_flow_error_set(error, ENOTSUP, > @@ -5313,6 +5315,18 @@ flow_dv_validate(struct rte_eth_dev *dev, const struct rte_flow_attr *attr, > NULL, "too many header modify" > " actions to support"); > } > + /* > + * Validation the NIC Egress flow on representor, except implicit > + * hairpin default egress flow with TX_QUEUE item, other flows not > + * work due to metadata regC0 mismatch. > + */ > + if ((!attr->transfer && attr->egress) && priv->representor && > + !(item_flags & MLX5_FLOW_ITEM_TX_QUEUE)) > + return rte_flow_error_set(error, EINVAL, > + RTE_FLOW_ERROR_TYPE_ITEM, > + NULL, > + "NIC egress rules on representors" > + " is not supported"); > return 0; > } > > @@ -7891,12 +7905,14 @@ __flow_dv_translate(struct rte_eth_dev *dev, > /* > * When E-Switch mode is enabled, we have two cases where we need to > * set the source port manually. > - * The first one, is in case of Nic steering rule, and the second is > - * E-Switch rule where no port_id item was found. In both cases > - * the source port is set according the current port in use. > + * The first one, is in case of NIC ingress steering rule, and the > + * second is E-Switch rule where no port_id item was found. > + * In both cases the source port is set according the current port > + * in use. > */ > if (!(item_flags & MLX5_FLOW_ITEM_PORT_ID) && > - (priv->representor || priv->master)) { > + (priv->representor || priv->master) && > + !(attr->egress && !attr->transfer)) { > if (flow_dv_translate_item_port_id(dev, match_mask, > match_value, NULL)) > return -rte_errno; > -- > 2.18.1 > -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd