From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EAF30C282CA for ; Sun, 27 Jan 2019 16:40:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B55BB2146E for ; Sun, 27 Jan 2019 16:40:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="gK5Z+Mf9" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726863AbfA0QkD (ORCPT ); Sun, 27 Jan 2019 11:40:03 -0500 Received: from mail-yw1-f65.google.com ([209.85.161.65]:36135 "EHLO mail-yw1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726832AbfA0QkD (ORCPT ); Sun, 27 Jan 2019 11:40:03 -0500 Received: by mail-yw1-f65.google.com with SMTP id i73so5846254ywg.3 for ; Sun, 27 Jan 2019 08:40:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wROC6RVFkpWSvtO8/vxuZ14wZlOghmCo696qIHNCUC8=; b=gK5Z+Mf9GnXv3lKPVi+ZEVD0mI7jn4OSFg5UP5DXblQCor19ZR574FkNEv45gBhAZJ 9TpLrzm6+sx48YdbbxGBoOqAUSzTJ5fT1TXRjCuyo3v/oXS6DLnzrphqST9/94X56uUn a3NWmCsQSHQd4Syh2y0eGwhC2TBzJCRbCO81amt4nymS96yvhjcQ30DJJ8fjteN/A1h4 AHNZ6eWD5b7T/49Y8xTF/25bYN27JjNXl8uDuCnSSkwjG0L0wiix/i08wSbihBcbKcTw MNiVo2OOwLgh4vt9x8EKXrd+RW27RKwBidNF+JDSj4fIxQzRhuf3l+VDm2+6+rtmRyHD jL9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wROC6RVFkpWSvtO8/vxuZ14wZlOghmCo696qIHNCUC8=; b=Y8Ahj2RecDlbCiFGtlhu6IkCRAvZJG2EESE9mjUNCak6xM+pbk4fiwANaGuWGPYEWy SnTVfLla+bW2gNKymP8qdkHXycthXALtwD+jGjKGCyuCNm2QvAPW4yRvQersy/1GiCn1 J7tx5q0lR1HFM4vHxp4shsTzgLuDoNYnhwSW26PD17lcE5cK7o4D2zlgbg7Ry0oapuPy /3kwItlSA3ILKqLuwhTsw7/IjNvHxr9ynLTcfdN/P1F/I8V/Rm9HyNj9CLLwcAfvsMTu rcFCyPG+E4xFxUICdHMFWhqt+60MdfxUigEaDVXNwinebMayhoQ79yknKVGmv1b8Y8WH PFkg== X-Gm-Message-State: AJcUukfGCPfafzJkIcyj841Uf1UlRHdVNIufllC82fv+2TzelXMOs1ur EMRQ0AgSJj5M5QYh7NGGvBJ6OK1J3MRkX/X37F930uT6PQU= X-Google-Smtp-Source: ALg8bN4hIB7fv+CTROepC3mkXL0rzBWIAttbP8urchB19vhS7X4w+id7cbAEP/s1sTR4kIyVqmVpZdMgkwCySl7tMt4= X-Received: by 2002:a81:202:: with SMTP id 2mr18543282ywc.291.1548607202345; Sun, 27 Jan 2019 08:40:02 -0800 (PST) MIME-Version: 1.0 References: <1548587196-10746-1-git-send-email-xiangxia.m.yue@gmail.com> <1548587196-10746-2-git-send-email-xiangxia.m.yue@gmail.com> In-Reply-To: <1548587196-10746-2-git-send-email-xiangxia.m.yue@gmail.com> From: Or Gerlitz Date: Sun, 27 Jan 2019 18:39:51 +0200 Message-ID: Subject: Re: [PATCH net v4 2/2] net/mlx5e: Don't overwrite pedit action when multiple pedit used To: Tonghao Zhang Cc: Saeed Mahameed , Linux Netdev List , Or Gerlitz Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sun, Jan 27, 2019 at 1:06 PM wrote: > From: Tonghao Zhang > > In some case, we may use multiple pedit actions to modify packets. > The command shown as below: the last pedit action is effective. > @@ -2073,7 +2076,8 @@ static int alloc_mod_hdr_actions(struct mlx5e_priv *priv, > if (!parse_attr->mod_hdr_actions) > return -ENOMEM; > > - parse_attr->num_mod_hdr_actions = max_actions; > + parse_attr->max_mod_hdr_actions = max_actions; > + parse_attr->num_mod_hdr_actions = 0; why would we want to do this zeroing? what purpose does it serve? On a probably related note, I suspect that the patch broke the caching we do for modify header contexts, see mlx5e_attach_mod_hdr where we look if a given set of modify header operations already has hw modify header context and we use it. To test that, put two tc rules with different matching but same set of modify header (pedit) actions and see that only one modify header context is used.