From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0083.outbound.protection.outlook.com [104.47.2.83]) by dpdk.org (Postfix) with ESMTP id 6E2B12C8; Wed, 23 May 2018 20:34:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=omtzy01sKYX6dW+CRdO1Y2mZsL5fxoGdEn3jucg8v7U=; b=mDeOtMs+aUfJipZxQBNO0283BBjBpsUB8yBHJ5AaeXRskXly8u3KZVed3x+P/D9DdHIijnmoFppKfi+1fFOujuB4xODO7i6vqXPxPDTvW2ALHZRk8TS3S8t7e9M/8NnGMKMsvqN8i9kzbB1/behXhNfVjy3p8F6mPGTTzvCryhQ= Received: from yongseok-MBP.local (209.116.155.178) by AM5PR0501MB2036.eurprd05.prod.outlook.com (2603:10a6:203:1a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.797.11; Wed, 23 May 2018 18:34:14 +0000 Date: Wed, 23 May 2018 11:34:01 -0700 From: Yongseok Koh To: Matan Azrad Cc: Shahaf Shuler , Adrien Mazarguil , =?iso-8859-1?Q?N=E9lio?= Laranjeiro , "dev@dpdk.org" , "stable@dpdk.org" , "Xueming(Steven) Li" Message-ID: <20180523183359.GA13339@yongseok-MBP.local> References: <20180523015157.35716-1-yskoh@mellanox.com> <20180523100116.GA11530@minint-98vp2qg> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.3 (2018-01-21) X-Originating-IP: [209.116.155.178] X-ClientProxiedBy: BYAPR02CA0025.namprd02.prod.outlook.com (2603:10b6:a02:ee::38) To AM5PR0501MB2036.eurprd05.prod.outlook.com (2603:10a6:203:1a::22) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(2017052603328)(7153060)(7193020); SRVR:AM5PR0501MB2036; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0501MB2036; 3:pm0zTUVIiTosgRNiETwRbycLimV+hQgTkdkedZqBxRapKKAlbMpgE8++47AJTXLS2cZsrJKvwz0ymBUDy94JNu0Nf+A7lvcjIhIuXCML2fOZNN5ftnjqmjvi2qnapMPgmQ3lNO4+Yd9UQOjH0nbwh3sAp7X2CwWilku0jFvhxfy3u9WmwoV66xX83S5hauR4nKVGk9Tq4ogXFjDF8nPoXybBiOA4Tv9nn7XGb0W/iLGzFi+mBhGB6RYJGpz/rgar; 25:5B7x6EP5pxmFxAkj+6oRIRiFke/yJmFs8+m7CU2/habcG8UWFs5ItZW5OUqcPTfirz+nyKNo8zi1zJJMfPVnXKK8StiaY8e0jA1w8BEbUyoPUxavTArk3xYwfQHlCZoqERLg9rolOVU8YBiP3DR9TrfPSqqL4YPkQlG53sUfmmIpWzrB+vDckEU8FB24IdJw9S/Zp+K+F43LQtP0UUM9jkjdPXaBV6p0kflLSWF5qohUgKWikEInCi/wQcQ5ySLUMoh9YpJRrGNzXKh2e1SwZBX/KYeYL2ieZ+cf2v/TQEd8RcNv2UGXR7s95Z4vCfdnQ0QH/1aEjLTrKIJLrhw1gA==; 31:r+5APlXtqejjFvBOOyxLo9wvGTKcOV4GJajdOqYBqsWkdRjbI0aYZJabn7/RDQzVpJAR/oThLEqJLEaAk6WOaXgiP6ZTXwE9GUS4QTnb7AZrgjerisQZ7gfJn/0dkv2XXfBb+AWsz2xXreB7hmRmt2XkLcHpWjaQCBSlWytDTwDVypX2B7biFwkEJBW1rxNZ/pdP9hOgCrFw+ogXh/KfXbOBs2w4etAfvDGiesYodBk= X-MS-TrafficTypeDiagnostic: AM5PR0501MB2036: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=yskoh@mellanox.com; X-LD-Processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; AM5PR0501MB2036; 20:i0m723e/1eHA+E83zdAkrJuT/iHdF8YkminSWe4Ti0ZluGBcqVhPAwW/nYVPXKYo34ZKDsdUgufCm13NJ2WRWH46QqBFBrv3boVb7CR0VHWtR8Dh5G8Dt3+Sz9GWnxHaLbS/pjh+pWnikrqCpIoRRO+S3VbxqHKkl3sBZhcNo9wecJ9bVoDVk4LvXaiFBphDyWjcduEA4IZCN58pftFzQF0ipdIBSwYmo+M1Tw+8YY86qbTph1JqCTaOYzGBlOgaXGiAQPqMtg+Esi4HhLFIA1pH1/iCR3eINLUNP0eTrS6gcxVxQcD6cAfdtSSiks62lIB1mNAAVfbyeReMRx677brLmjg28sC5h+ym2bkO7oxLDgpuNCAlz+KGmlzHkHN4Eh7/VAOvUL45hAwF0khNJOzIwYn5GU5jcmt+JOE3nQNOHR/fR/y7cNbCu8HEMaH1jUQUbju/Zsunf/xA5iJ2Yn+WMKi+mmWRGy7LUu9fPbKQwgw4Q7EXnGumguR+eO4Q; 4:ZraTsbKaKfS9KRuGopi5Z30cBYMBFnz0/KyBdtmfbMpOvkKdMkpbQMYpudDtpKNT3Mz25PUdvYUM3Q0y0k+mSdAftqCc5uL+17XKCgbsti6SMVxQD9v4v6AINxIXGshcAUZpIrubDMDuZJhPZ5g+vUZ0eMr2tT21CJ4ToMtgucUqwSweQm+0PEEJEZsZbhoTc5GVJEJ3ZxyHosp3lmZpvEZnGQP0GhTv2J3F0q6C+sZw0L0pWSKRMVwDim11lAe6THYzgsdLoZwmKxmHyB9S2sGIDJjGOCskBGCZP7K/Fuj6k5nhvbk2bMH0BLaOtfr2 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231254)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:AM5PR0501MB2036; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0501MB2036; X-Forefront-PRVS: 06818431B9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(979002)(39860400002)(39380400002)(376002)(366004)(346002)(396003)(189003)(199004)(51444003)(47776003)(66066001)(486006)(956004)(478600001)(476003)(2906002)(50466002)(11346002)(106356001)(8936002)(105586002)(446003)(97736004)(25786009)(4326008)(5660300001)(54906003)(9686003)(7736002)(76176011)(575784001)(86362001)(305945005)(55016002)(81156014)(8676002)(16586007)(58126008)(81166006)(6862004)(68736007)(98436002)(229853002)(33656002)(16526019)(53936002)(316002)(1076002)(93886005)(6636002)(23726003)(6246003)(3846002)(33896004)(52116002)(7696005)(6116002)(6666003)(6506007)(107886003)(26005)(386003)(18370500001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0501MB2036; H:yongseok-MBP.local; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; Received-SPF: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM5PR0501MB2036; 23:W3M3uFlQGf7kuM8VhlJSlBL7yedFQwoaZSsMSAN?= =?us-ascii?Q?6VBgsTuZbvmF8rAdZX7mT9OAp1gAi8M9Nh8jNe3dg2WNWScRbgVJncxozQDM?= =?us-ascii?Q?dGFVD1BnY7fDT5gexFDfD/Uz4OCLjUVegbDHiRLxEKgUKgCR+TtbyvvPrQPg?= =?us-ascii?Q?4Ol+4qm4dftKsDpsUYvoPjWonYI8UCvvSB57UhSoEkZZ2Fg5L3yZf631KELX?= =?us-ascii?Q?U6NdbZ1zIZChEs0n7PQJwwQQ7JuMdkG78UsjXehiQIrPMXzoAJCK/FpRz5ml?= =?us-ascii?Q?BDweGKpsPySJZuPLNmey/v5HsOLKn2+wSzGpEcJfXTg/7KXp03pG3V/2d+2Y?= =?us-ascii?Q?ad/3d0d/aX7YXD+3v3e2zaWhc88toPWHuAinFQ1hpe5ZuTyM+D4I2YhJt1XO?= =?us-ascii?Q?QAyoxo/XixA3DI4mqvKsA8aadKohUf7HXOMRbdSTBIqSJVM0ccHQrasYHR4L?= =?us-ascii?Q?PbaMUgFIp/qy+7IztXjj44mc3vhc4JZuY9TNxWeF4JZoWZ92lH5X7z1sfkEl?= =?us-ascii?Q?ceRotRfvmaMFAZX/eiGYFLfRCKrvKAiv8SmSn/aHyBqM+Bb3YNPwxPnFKvgY?= =?us-ascii?Q?mQdxnMKWZsD/a60Q2wQGn/5u/IXmwvYRhgEl8EQxTQQOdBNsebesZJaTMglP?= =?us-ascii?Q?U9/TyUDok72ph2/RMzWZE7hawFGcigyJYc1HcyHRYCtsEFvM7GSq6hhKG6YT?= =?us-ascii?Q?LEf//xIeKABuIO79HKIqhxJ9l+4Q2LzUX8XsC5Z/vaWdaO1QnYkECZ86zSmP?= =?us-ascii?Q?QSYsYu7FIbeVLFiRg4tWmT+P++EOAZrU958IOBIG4nSXNF7myNjrlsaPuL2l?= =?us-ascii?Q?LraJpbg4BBrR/P4L206Ugo3TpD++0BCpFn6NAwlV73/BK3vp8KS+6cCCAZJ3?= =?us-ascii?Q?piOz+ScPR5CmmdmZ8gwLEzgIbFZH8zA3zpM9affLrbRyDk6vAtdT96vIkNRZ?= =?us-ascii?Q?DBW3HVdUyYw+Hh1q1CaHFvrzBw17Rzxq4EHXBsSJ7RrOJHGIIuFD3lFpk7xX?= =?us-ascii?Q?Uub4cnEjPXl25w4Wr6QY7BARG8F+VH3yCMduiae09ER4hXs00zCwclDOnfWM?= =?us-ascii?Q?rmimHhTUEbttcYeUP6KTSqCYV7Bt6ofvdbW3Zmbzspo9XUID5FUVNuMR/n/N?= =?us-ascii?Q?NMFk38U54pWpI/TGBhmxr9CO8d+i60JuSwF78DR0lhu0osE9J91K2qXzkJxw?= =?us-ascii?Q?gxNAwx/VCMp405zReNNMElpSgQFA+RyvyglcBDN0ugWYGFohebA3CFa58gYB?= =?us-ascii?Q?yh3c/eAHsKh/JOt7yzDllC1SoXE6BZJmPtzd4tyTC4XLvs6L2xVzDP0GPmHc?= =?us-ascii?Q?afemCZxrxlgPd1Owq495NieSUZ36ozjY9TZ6tpo2JKmXsgWpB5jyfw6NVhpW?= =?us-ascii?Q?4BW8+fHriaxvBkuH3ql1WVxf/Ol/NgFYuwe2si1g80eYZcXryL7oTMvDSC3k?= =?us-ascii?Q?uPBf/SEr5/3U2ViLlieEkYnM1N6UHVS12w/+BoJxdAw0w+t/+pcY5y46R+b6?= =?us-ascii?Q?l8Sbak23gl+vyfQazuaLj+U+/UFMj7oK0P8k=3D?= X-Microsoft-Antispam-Message-Info: tZ/MsM4n+JemfDIbxBfkzwF8a8QojFYsjDv0xUmc0jMIA0ljSNHfz0A00N0Zx1fTnrvclRuxM5xCIfFhVCj7P+2wj2Y5RnPkAwcqiWx/a4FXiWjgbaXeopf/z976vSb0D6jZF2n/viSO6hWYayy7QouE62qDpkuaEZWhUnQUWmMJveF9+j9qKIOE29oB5Ep+ X-Microsoft-Exchange-Diagnostics: 1; AM5PR0501MB2036; 6:87WxQzQjdc8JI2+bEle3Dbolt8dvwLEzw68qKq1+4J/zatYck4A+FU7+TvVW9SKDLFomJhsTeAMtu/as1oeeLZKuNgXrnT2VZsIr8Ny9R6yrJBiO2jEVWQ3NP1suSzNXtI2h4VYGwO2RbvxTW3rwpHntAAqRoJ2VHMTFxm+nkYg/iQEiMxyXx9gudzpQMzJtK0rUVQPlJ09DEDXcwntxv2jQ+IAFf9y6OMbGd+g0KQU2TyE3gwxVWRABORXRtQOK8aE7/8ydbYTFsAHa+z2twxf3PsiqaGLfT1QMBwrkccAbatHg7yQ97/mreIn9OQfH2iwg5BSyIoVYdrh3onxh/T5oGgER7xnNL/UbNeOLA5leiElumpWuvQnGWJW4aqn/OaCssADbkgHUpzHDFMmbMOw8Tj9kswaFCEFbKJPaL4Y1r9W7UdWNOUiJc8FelBc7fT2SrBcj7LO+xA+Ht2MTjQ==; 5:5aK64HVrqKTzaRWX28qqQ6pT0ugDtkHzuwSAwt87rRdSDFIwDG6fLvqKAND31UiwuSFuexDUkkB2FWUK0p4xk18ykQZN2mi7LNPGsE7yE11xEXmAF8sDLsz0aldECfUzpUXbRGI3e855XET8FcBuDEnSXtTTZNoXVABMEXS/Dzs=; 24:ki4BfHjRgOs4nCfE00Xgdt3b8GXN67HLtBUjOjqFSqGhSGF/RoqG3mYIY6DY7njhfOCzAGZtDiJRqpryy8Ue3ZhWrt+4drzc0VbhWiNMG0U= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0501MB2036; 7:VwM9KrIeQ2PEaLB2fQPdyqCpObxWwm4USbOxncrm0HBDRIqrD5QihABElGgNoULiXBVwsmkYFE0aoeQN15e7ASyEgQwd41Ts/clpLdU+Py3yTNQCe36kL7A1yfOZQHnz5RttjxujgHDf1XqXSr+1GYnFx83ShPD01Rs69/U4KqRCydzvff1YwY+FtreNXpusPuo3BzZSCbXj2LGOsqMMCwE6oapaI4C1+Rq2Qv9Ie26nzP+qFB1QOtRbZzS12mAn X-MS-Office365-Filtering-Correlation-Id: c3ff2bf5-5012-46ed-d6b4-08d5c0dbc9e6 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 May 2018 18:34:14.6671 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c3ff2bf5-5012-46ed-d6b4-08d5c0dbc9e6 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0501MB2036 Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] net/mlx5: fix GRE flow rule X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 18:34:18 -0000 On Wed, May 23, 2018 at 04:45:33AM -0700, Matan Azrad wrote: > > Hi Yongseok > + Steven > > From: Yongseok Koh > > On Tue, May 22, 2018 at 10:36:43PM -0700, Matan Azrad wrote: > > > Hi Yongseok > > > > > > From: Yongseok Koh > > > > Creating a flow having pattern from the middle of a packet is > > > > allowed. For example, > > > > > > > > testpmd> flow create 0 ingress pattern vxlan vni is 20 / end actions ... > > > > > > > > Device can parse GRE header but without proper support from library > > > > and firmware (HAVE_IBV_DEVICE_MPLS_SUPPORT), a field in GRE header > > > > can't be specified when creating a rule. As a result, the following > > > > rule will be interpreted as a wildcard rule, which always matches any > > packet. > > > > > > > > testpmd> flow create 0 ingress pattern gre / end actions ... > > > > Fixes: 96c6c65a10d2 ("net/mlx5: support GRE tunnel flow") > > > > Fixes: 1f106da2bf7b ("net/mlx5: support MPLS-in-GRE and > > > > MPLS-in-UDP") > > > > Cc: stable@dpdk.org > > > > > > > > Signed-off-by: Yongseok Koh > > > > --- > > > > drivers/net/mlx5/mlx5_flow.c | 6 ++++-- > > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/net/mlx5/mlx5_flow.c > > > > b/drivers/net/mlx5/mlx5_flow.c index 994be05be..526fe6b0e 100644 > > > > --- a/drivers/net/mlx5/mlx5_flow.c > > > > +++ b/drivers/net/mlx5/mlx5_flow.c > > > > @@ -330,9 +330,11 @@ static const enum rte_flow_action_type > > > > valid_actions[] = { static const struct mlx5_flow_items mlx5_flow_items[] = > > { > > > > [RTE_FLOW_ITEM_TYPE_END] = { > > > > .items = ITEMS(RTE_FLOW_ITEM_TYPE_ETH, > > > > +#ifdef HAVE_IBV_DEVICE_MPLS_SUPPORT > > > > > > The GRE item was here even before the MPLSoGRE support > > > > Yes, this bug has existed before adding MPLSoGRE support. > > > > > so I think that this is not the correct fix and even that it can hurt > > > the support of GRE for the current customers use it. > > > > How can it hurt? Please clarify. > > Someone who uses the next flow and have not the new verbs version of MPLS: > flow create 0 ingress pattern gre / ipv4 src is X / end actions ... > ipv4 src or any other inner specifications. > > This flow will probably get any supported tunnel packets with inner ipv4 src = X. Do you think we should compromise? This is logically wrong for sure. Let me give you a specific example. If I create the following two flows, flow create 0 ingress pattern vxlan vni is 10 / end actions queue index 3 / mark id 10 / end flow create 0 ingress pattern vxlan vni is 20 / end actions queue index 3 / mark id 20 / end The following two packets will match correctly and have flow ID (10 and 20) according to VNI. Ether()/IP()/UDP()/VXLAN(vni=10)/Ether()/IPv6() Ether()/IP()/UDP()/VXLAN(vni=20)/Ether()/IPv6() However, if three flows are created as follows, flow create 0 ingress pattern gre / ipv6 / end actions queue index 3 / mark id 2 / end flow create 0 ingress pattern vxlan vni is 10 / end actions queue index 3 / mark id 10 / end flow create 0 ingress pattern vxlan vni is 20 / end actions queue index 3 / mark id 20 / end The packets will hit the first flow regardless of VNI and have wrong flow ID. That's why I have to drop this specific GRE case. Whoever is using this kind of GRE flow, that's buggy anyway. They have to know it and change it. > It may be enough for the current user (which probably use only 1 tunnel type at a certain time). Router/switch-like applications can have multiple tunnels for sure. I'm not sure who 'the current user' is but I don't think we can make such an assumption. I don't want to allow users create faulty flows. > > > Looks like you must specify at least 1 spec in the GRE to apply it > > > correctly as you did for VXLAN, Can you try empty vxlan and fully gre > > > (with protocol field)? > > > > That's exactly the reason why I'm taking this out. If you look at the code, it > > doesn't even set any field for GRE if HAVE_IBV_DEVICE_MPLS_SUPPORT isn't > > supported. Thus, it is considered as a wildcard (all-matching) rule. But if it has > > HAVE_IBV_DEVICE_MPLS_SUPPORT, such pattern can be allowed. > > Yes, so your GRE flow will not work even if you have MPLS support. I'm not sure what you meant but with IBV MPLS support, I think IBV_FLOW_SPEC_GRE will make things right. Without the support, IBV_FLOW_SPEC_VXLAN_TUNNEL is even set for GRE flows. > I think the issue is generally in all the items: > You should not configure them if they miss both at least one > self-specification or item which points to them by "next protocol" field. > > In case of VXLAN tunnels we just don't allow them without self-specification, > In case of gre we force the next protocol of the previous item but only when it exists. > In case of eth(inner),vlan,ipv4,ipv6,udp,tcp we don't force anything. > > I think we need a global fix for all, this is probably the root cause. Well, the root-cause is that old device/lib doesn't differentiate GRE from VXLAN when creating flows. Thanks, Yongseok > > Having pattern 'vxlan' without vni isn't allowed by mlx5 PMD because zero VNI > > is never accepted. > > > > Thanks, > > Yongseok > > > > > > + RTE_FLOW_ITEM_TYPE_GRE, > > > > +#endif > > > > RTE_FLOW_ITEM_TYPE_VXLAN, > > > > - RTE_FLOW_ITEM_TYPE_VXLAN_GPE, > > > > - RTE_FLOW_ITEM_TYPE_GRE), > > > > + RTE_FLOW_ITEM_TYPE_VXLAN_GPE), > > > > }, > > > > [RTE_FLOW_ITEM_TYPE_ETH] = { > > > > .items = ITEMS(RTE_FLOW_ITEM_TYPE_VLAN, > > > > > > > > >