From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) by dpdk.org (Postfix) with ESMTP id 9A09558FE for ; Wed, 3 Apr 2019 10:30:00 +0200 (CEST) Received: by mail-pf1-f182.google.com with SMTP id r15so7765403pfn.9 for ; Wed, 03 Apr 2019 01:30:00 -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=Eowh28KpPXCydxx6onsV/VK7w/23tTfrKf5VJIsX8kc=; b=A5ySFmk4rstJFP1a8Z88mlINrL34LTLjFj2k5wJifuMAJTkldIp6M10qiCWnrBOgSY FHOGVrP00p/2JeBdySEDwPQuStJUWBsnZ7YBu6WgAE5/krrsvPN95nh82iIHBQs02fvb qQK+nPkD8zFR+ed+ielxxDNTiedxgXh4mTTle/+ei2sq+l/qkVcNqEziAsboA9ToSFaW kpuex50Mo+bkDDidZIy7+G8l2Gn3oC5B2VHZdVuXMOnGbjOljU6khHF7CxC1FmdfDuzc 8UR0kIlhnx1EA7u/4KkoI4uVFzgnV9q2TDjNoaxlRKsnksX0o4mXvQ3Zl7QcgMlZokrt Jd3A== 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=Eowh28KpPXCydxx6onsV/VK7w/23tTfrKf5VJIsX8kc=; b=Do1FTJVwAVdr89BW1ASbzsUzDWti0GCgVn/KlMnE+uCen46ClvzpUUmZlH7TOG/id0 hYCw0Da+fcR1x8mz8ZHxkKSzdTVCuMkgLhktGPn9Ze8WkTitKu78jD7g3CJV4fnnXb1a BVihKfOZKM96UXaFD5ZoXgN4WfcvPLS9USrLuOgRvCl2BuIjveJADvSy0n5oSwFrvTZB WzHsEP0JV/K1t/LMM3kRrGlhG58pLdmVtVBfpDV+H33n/9PxZ1/KzxQDEdLfv5ppCTGN PGEcxrSAuEFDTx0qz8jWHMD1pEBfw8/IYUfJfphZBfH1RM8hQ8JE+dvonGXUKLheze1i qFNg== X-Gm-Message-State: APjAAAVfDp27CTM0GDvpDFHNaD0LeppoErOLSg0D5+unvRKWA7KZnBuN XxNIuq7AefdfvJe2EOT5f/8= X-Google-Smtp-Source: APXvYqyF8kuIVgOMh6WekDrryvOKHTrknzSbqPD7Q3bHBdSAXHKIpAQaifIzXbhVZ2lUHcq9jIYF6A== X-Received: by 2002:a63:e70c:: with SMTP id b12mr71734223pgi.399.1554280199774; Wed, 03 Apr 2019 01:29:59 -0700 (PDT) Received: from [10.2.211.140] ([61.120.150.70]) by smtp.gmail.com with ESMTPSA id u13sm33544666pfa.169.2019.04.03.01.29.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Apr 2019 01:29:59 -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: <2D0CB568-B970-408A-9463-5D05D201370A@gmail.com> Date: Wed, 3 Apr 2019 16:29:55 +0800 Cc: dev@dpdk.org Content-Transfer-Encoding: quoted-printable Message-Id: <1FA542CD-78EC-4FA0-B48E-C768010CD431@gmail.com> References: <2D0CB568-B970-408A-9463-5D05D201370A@gmail.com> To: dekelp@mellanox.com 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: , X-List-Received-Date: Wed, 03 Apr 2019 08:30:00 -0000 +Dekel Add Dekel to see if this is an issue. Thanks, Daniel > 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 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 34EACA0679 for ; Wed, 3 Apr 2019 10:30:02 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AC11A5F0F; Wed, 3 Apr 2019 10:30:01 +0200 (CEST) Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) by dpdk.org (Postfix) with ESMTP id 9A09558FE for ; Wed, 3 Apr 2019 10:30:00 +0200 (CEST) Received: by mail-pf1-f182.google.com with SMTP id r15so7765403pfn.9 for ; Wed, 03 Apr 2019 01:30:00 -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=Eowh28KpPXCydxx6onsV/VK7w/23tTfrKf5VJIsX8kc=; b=A5ySFmk4rstJFP1a8Z88mlINrL34LTLjFj2k5wJifuMAJTkldIp6M10qiCWnrBOgSY FHOGVrP00p/2JeBdySEDwPQuStJUWBsnZ7YBu6WgAE5/krrsvPN95nh82iIHBQs02fvb qQK+nPkD8zFR+ed+ielxxDNTiedxgXh4mTTle/+ei2sq+l/qkVcNqEziAsboA9ToSFaW kpuex50Mo+bkDDidZIy7+G8l2Gn3oC5B2VHZdVuXMOnGbjOljU6khHF7CxC1FmdfDuzc 8UR0kIlhnx1EA7u/4KkoI4uVFzgnV9q2TDjNoaxlRKsnksX0o4mXvQ3Zl7QcgMlZokrt Jd3A== 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=Eowh28KpPXCydxx6onsV/VK7w/23tTfrKf5VJIsX8kc=; b=Do1FTJVwAVdr89BW1ASbzsUzDWti0GCgVn/KlMnE+uCen46ClvzpUUmZlH7TOG/id0 hYCw0Da+fcR1x8mz8ZHxkKSzdTVCuMkgLhktGPn9Ze8WkTitKu78jD7g3CJV4fnnXb1a BVihKfOZKM96UXaFD5ZoXgN4WfcvPLS9USrLuOgRvCl2BuIjveJADvSy0n5oSwFrvTZB WzHsEP0JV/K1t/LMM3kRrGlhG58pLdmVtVBfpDV+H33n/9PxZ1/KzxQDEdLfv5ppCTGN PGEcxrSAuEFDTx0qz8jWHMD1pEBfw8/IYUfJfphZBfH1RM8hQ8JE+dvonGXUKLheze1i qFNg== X-Gm-Message-State: APjAAAVfDp27CTM0GDvpDFHNaD0LeppoErOLSg0D5+unvRKWA7KZnBuN XxNIuq7AefdfvJe2EOT5f/8= X-Google-Smtp-Source: APXvYqyF8kuIVgOMh6WekDrryvOKHTrknzSbqPD7Q3bHBdSAXHKIpAQaifIzXbhVZ2lUHcq9jIYF6A== X-Received: by 2002:a63:e70c:: with SMTP id b12mr71734223pgi.399.1554280199774; Wed, 03 Apr 2019 01:29:59 -0700 (PDT) Received: from [10.2.211.140] ([61.120.150.70]) by smtp.gmail.com with ESMTPSA id u13sm33544666pfa.169.2019.04.03.01.29.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Apr 2019 01:29:59 -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: <2D0CB568-B970-408A-9463-5D05D201370A@gmail.com> Date: Wed, 3 Apr 2019 16:29:55 +0800 Cc: dev@dpdk.org Content-Transfer-Encoding: quoted-printable Message-Id: <1FA542CD-78EC-4FA0-B48E-C768010CD431@gmail.com> References: <2D0CB568-B970-408A-9463-5D05D201370A@gmail.com> To: dekelp@mellanox.com 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: <20190403082955.bGk6hwTr83OBotPHDJwU7VeGvfF069E0L_kE1aePgNY@z> +Dekel Add Dekel to see if this is an issue. Thanks, Daniel > 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