From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0068.outbound.protection.outlook.com [104.47.0.68]) by dpdk.org (Postfix) with ESMTP id 412921D7; Thu, 24 May 2018 08:34:07 +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=M7nxSUuWxkZpOREn61yiUH791hYMA8J6/jcutqkd/+Y=; b=Ko9fI1uqdePjtdVZd8slw+R7kl5FYIBHP3jchlusw0U/8TO3fBHUkI1kFp2jecHBUujGJCF8CT8flyPTimzc+STBhxWmpISsksF4L657s0s7GW6IctR7GX3tW0FYFwoi9lYCySbL03M4bkhnbyavZRKSeVsiFxFM5anJtcGLfvQ= Received: from VI1PR0501MB2608.eurprd05.prod.outlook.com (10.168.137.20) by VI1PR0501MB3582.eurprd05.prod.outlook.com (10.166.198.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.797.11; Thu, 24 May 2018 06:34:02 +0000 Received: from VI1PR0501MB2608.eurprd05.prod.outlook.com ([fe80::1035:58f9:b94c:2180]) by VI1PR0501MB2608.eurprd05.prod.outlook.com ([fe80::1035:58f9:b94c:2180%18]) with mapi id 15.20.0776.015; Thu, 24 May 2018 06:34:01 +0000 From: Matan Azrad To: Yongseok Koh CC: Shahaf Shuler , Adrien Mazarguil , =?iso-8859-1?Q?N=E9lio_Laranjeiro?= , "dev@dpdk.org" , "stable@dpdk.org" , "Xueming(Steven) Li" Thread-Topic: [dpdk-dev] [PATCH] net/mlx5: fix GRE flow rule Thread-Index: AQHT8ji4UdW7+yaJAE27AdV43Ftbk6Q8wtFAgABSvgCAAARNsIAAiu+AgAALDKA= Date: Thu, 24 May 2018 06:34:01 +0000 Message-ID: References: <20180523015157.35716-1-yskoh@mellanox.com> <20180523100116.GA11530@minint-98vp2qg> <20180523183359.GA13339@yongseok-MBP.local> In-Reply-To: <20180523183359.GA13339@yongseok-MBP.local> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=matan@mellanox.com; x-originating-ip: [193.47.165.251] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0501MB3582; 7:GaBw7Vd++IyzrOvw6ko4X70ofCNGFNThfq6fg6+T6ZQ0UUPsrujfe5gzcvYQrmJ5xtRwLZHEBOJaEFVZgCg3V1gB09oyxas4OVd785EvQVZVpqqPAtOn1q0Z7zGngr85KOkR4dqirISN68EeTJCbNS7eg3+RQ8FrUAI3oyPTkpjUsCdplwTVHmMGgTjtwYye3HBc+1nU9oLe//2Yf8jw3q90RPdmsmBybVLeSMvuxbQhhmVFcoEdB9Ec5d+n9xAU x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0501MB3582; x-ms-traffictypediagnostic: VI1PR0501MB3582: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr 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)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:VI1PR0501MB3582; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0501MB3582; x-forefront-prvs: 0682FC00E8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(376002)(39860400002)(346002)(366004)(39380400002)(396003)(51444003)(189003)(199004)(9686003)(316002)(229853002)(54906003)(6636002)(5250100002)(3660700001)(55016002)(97736004)(8936002)(81166006)(486006)(2906002)(14454004)(74316002)(446003)(25786009)(476003)(5660300001)(11346002)(81156014)(2900100001)(8676002)(53936002)(4326008)(33656002)(7736002)(305945005)(26005)(86362001)(6506007)(102836004)(6246003)(107886003)(68736007)(66066001)(106356001)(105586002)(478600001)(6862004)(6436002)(3280700002)(76176011)(99286004)(6116002)(3846002)(7696005)(93886005)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0501MB3582; H:VI1PR0501MB2608.eurprd05.prod.outlook.com; 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-antispam-message-info: dsW/wdOZbb7DqNlrDWdFhAj6wbGW85w/o5Yrx9pTMNbn/w42k8es9Y6GP9wUeaLzuuPVy55rnK4cbUPi+eI2xrnJDXG6mLWQI8oq3O6jqz0wfBjA080aWN+JYfgyDuZQc0pvGchvVERG0s6AK+2FaHVoDX3RYo/WC6SapZdkoXn0geDREiDg3IxGu0Q2MpJA spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: b0c2bfb1-a1b1-422c-ef84-08d5c14056a6 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: b0c2bfb1-a1b1-422c-ef84-08d5c14056a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2018 06:34:01.7235 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0501MB3582 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: Thu, 24 May 2018 06:34:07 -0000 Hi Yongseok From: Yongseok Koh > 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 > > > > > +#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 MP= LS: > > 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 ipv= 4 src =3D > X. >=20 > Do you think we should compromise?=20 For sure, no, I'm just want the correct fix, like you :)=20 >This is logically wrong for sure. Let me > give you a specific example. >=20 > If I create the following two flows, >=20 > 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 >=20 > The following two packets will match correctly and have flow ID (10 and 2= 0) > according to VNI. >=20 > Ether()/IP()/UDP()/VXLAN(vni=3D10)/Ether()/IPv6() > Ether()/IP()/UDP()/VXLAN(vni=3D20)/Ether()/IPv6() >=20 > However, if three flows are created as follows, >=20 > 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 >=20 > 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 k= ind of > GRE flow, that's buggy anyway. They have to know it and change it. I have just checked, the next flow under MPLS support doesn't get neither G= RE packet nor non GRE packet: flow create 0 ingress pattern gre / end actions queue index 3 / mark id 2 / end The issue is that in the first implementation of GRE tunnel we didn't force= d L3 next protocol to be GRE in this case because L3 is not in the pattern. > > It may be enough for the current user (which probably use only 1 tunnel= type > at a certain time). >=20 > Router/switch-like applications can have multiple tunnels for sure. I'm n= ot sure > who 'the current user' is but I don't think we can make such an assumptio= n. > I don't want to allow users create faulty flows. I never take such like assumption, just saying...(you can forget it) The point is that we may have a customer which the current behavior of=20 flow create 0 ingress pattern gre / ipv6 .../ end actions queue index 3 / m= ark id 2 / end is good for him and now after this fix it will fail in port creation(low pr= obability). >=20 > > > > 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. >=20 > 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. >=20 > > 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" fiel= d. > > > > 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 pr= evious > 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. >=20 > Well, the root-cause is that old device/lib doesn't differentiate GRE fro= m VXLAN > when creating flows. OK, let's continue with GRE only and will discuss about other protocol late= r in the next release. I think that the root cause is at least lack of GRE detection by next proto= col field in the outer L3 in case of first GRE item(verbs limitation). We can remove this option at all or to fix it by forcing L3 next protocol = =3D GRE in this case as done when we have L3 item before the GRE. =20