From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id E5079A0679 for ; Thu, 4 Apr 2019 14:12:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 726A51B212; Thu, 4 Apr 2019 14:12:23 +0200 (CEST) Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by dpdk.org (Postfix) with ESMTP id A0DEE1B207 for ; Thu, 4 Apr 2019 14:12:21 +0200 (CEST) Received: by mail-pl1-f178.google.com with SMTP id m10so1075770plt.10 for ; Thu, 04 Apr 2019 05:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zYPAC4oxep23vSTWGJ0nmKaSQt0WJblvNkYqLvMTP2I=; b=U0LPMoa1oyNx8+M5vb9TmDIa3XL7XruOn//BD2MEFyl3oNCO9li50YVnAbpiiL6LHk t3znvMsNImS3+8CB9gksvdScPlCZkaf7QjfdJQCXRG63E7fSRZviiKnY+5T9ysEgDVTi r5er17C5ubrJMeYRuHvHSkrLZDXD9TbABgOJCPXyWfVHOE4Ka/pdTMu6wUJk/+D+jp8l qyVfjclFAvX9kbSQlG+IC1BdjGml6X7ORGnv1lwVRy0cACCR3EGa1jFg93qOKOv710Qc MY+pWw+zCcnBo0/Iw3uE0bSC8UHkIiDGdT6IQaSo7UVO4AgBffh1IdYn8R/XWaFqF/lS ZmuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zYPAC4oxep23vSTWGJ0nmKaSQt0WJblvNkYqLvMTP2I=; b=lOKcxpf80Kfg3acb4u1AFqInEh4/dIYoBBH9D0AwiDjhhcHARD/fhNJKTru/vP9ns1 PGXVxxKhcf1YmqIJt7521RjBgC1l/B35JcMQASM0AJ+MzwmeoOBv9dmxEJnPlPQ99E/q xD0Cbfp8mRr0s0RBesVH/0QCXj02d66/BosIZalJAETb+LiG/U9SCyfSGE6bK6KNUDdX lPJF0E7luMxCznj9StwK/nBD0jezOtjcnksX1/hP9Gnb6smVOoKsncT8Uto9E88MznoI TKeuUT2D6ZgSK5oodTtAzHnDPuIIXgO7D+cZRCYfEFTJLMh7YGYMhrINA9Z5K+hJtgpX lNvQ== X-Gm-Message-State: APjAAAVUN3IUZWZYZUAMJqT+utNNaQEidyo99kF7wSRJl80Apyd07X7W pFCNLxXgZeiqUI4XsZNHQdM8Fsnc X-Google-Smtp-Source: APXvYqzyf/eqOZgy++FYkDbQXrJnWVqOvPrZvfq3U0Vb/+I8jxzTIrDK936F+1i+iWeoTdmaj0QBcg== X-Received: by 2002:a17:902:8bc3:: with SMTP id r3mr6158589plo.53.1554379940780; Thu, 04 Apr 2019 05:12:20 -0700 (PDT) Received: from [10.2.211.140] ([61.120.150.70]) by smtp.gmail.com with ESMTPSA id 17sm39620402pfw.65.2019.04.04.05.12.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Apr 2019 05:12:20 -0700 (PDT) Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: benli ye In-Reply-To: Date: Thu, 4 Apr 2019 20:12:16 +0800 Cc: "dev@dpdk.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D0CB568-B970-408A-9463-5D05D201370A@gmail.com> <1FA542CD-78EC-4FA0-B48E-C768010CD431@gmail.com> To: Dekel Peled X-Mailer: Apple Mail (2.3445.102.3) Subject: Re: [dpdk-dev] mlx5 FDIR rule comparison issue X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190404121216.sVTciGuXTrF0_QPXSKqrjppU2gTwwIUCgkcxzTIr_mg@z> Thanks Dekel for your information. I will have a try. Bests, Daniel > On Apr 4, 2019, at 7:18 PM, Dekel Peled wrote: >=20 > Hi Daniel, >=20 > The flow_director API will be deprecated in the near future. > It was replaced by rte_flow API, which contains much more features, = and is fully supported by Mellanox. >=20 > It is recommended that you use rte_flow API in your application. >=20 > Regards, > Dekel >=20 >> -----Original Message----- >> From: benli ye >> Sent: Wednesday, April 3, 2019 11:30 AM >> To: Dekel Peled >> Cc: dev@dpdk.org >> Subject: Re: mlx5 FDIR rule comparison issue >>=20 >> +Dekel >>=20 >> Add Dekel to see if this is an issue. >>=20 >> Thanks, >> Daniel >>=20 >>> On Apr 2, 2019, at 3:23 PM, benli ye = wrote: >>>=20 >>> Hi Developers, >>>=20 >>> I am adding two FDIR rule (one is for UDP and the other is for TCP) = for mlx5 >> pmd driver. The rules are listed below. >>> struct rte_eth_fdir_filter filt[MAX_FDIR_PROTO] =3D { >>> { >>> .input.flow_type =3D RTE_ETH_FLOW_NONFRAG_IPV4_TCP, >>> .input.flow.tcp4_flow.ip.dst_ip =3D dip, >>> .input.flow.tcp4_flow.dst_port =3D dport, >>>=20 >>> .action.behavior =3D RTE_ETH_FDIR_ACCEPT, >>> .action.report_status =3D RTE_ETH_FDIR_REPORT_ID, >>> .soft_id =3D 0, >>> }, >>> { >>> .input.flow_type =3D RTE_ETH_FLOW_NONFRAG_IPV4_UDP, >>> .input.flow.udp4_flow.ip.dst_ip =3D dip, >>> .input.flow.udp4_flow.dst_port =3D dport, >>>=20 >>> .action.behavior =3D RTE_ETH_FDIR_ACCEPT, >>> .action.report_status =3D RTE_ETH_FDIR_REPORT_ID, >>> .soft_id =3D 1, >>> }, >>> }; >>>=20 >>> However, mlx5 lib prevent me to doing this as when it treats the two = rules >> are the same. >>>=20 >>> I debugged for a while and found flow_fdir_cmp() didn=E2=80=99t = compare the >> protocol type in field items of struct mlx5_fdir. So should this be a = bug for >> mlx5? >>>=20 >>> flow_fdir_cmp(const struct mlx5_fdir *f1, const struct mlx5_fdir = *f2) >>> { >>> if (FLOW_FDIR_CMP(f1, f2, attr) || >>> FLOW_FDIR_CMP(f1, f2, l2) || >>> FLOW_FDIR_CMP(f1, f2, l2_mask) || >>> FLOW_FDIR_CMP(f1, f2, l3) || >>> FLOW_FDIR_CMP(f1, f2, l3_mask) || >>> FLOW_FDIR_CMP(f1, f2, l4) || >>> FLOW_FDIR_CMP(f1, f2, l4_mask) || >>> FLOW_FDIR_CMP(f1, f2, actions[0].type)) >>> return 1; >>> if (f1->actions[0].type =3D=3D RTE_FLOW_ACTION_TYPE_QUEUE && >>> FLOW_FDIR_CMP(f1, f2, queue)) >>> return 1; >>> return 0; >>> } >>>=20 >>> Thanks, >>> Daniel >=20