From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80078.outbound.protection.outlook.com [40.107.8.78]) by dpdk.org (Postfix) with ESMTP id DA0D81B462 for ; Thu, 12 Jul 2018 20:49:32 +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=DtHw6vJNey37PdUapqZKCo0wn2XywJGhoLpQGk6Qkcc=; b=Z2/5VnF3XM05PvatuKMitsuKM0sUQOtaX7LY1POL+VBe8tq/hAcqsqqGn2nLWuCG2OwcAx5quPBCgdkaJwwA2jIPaytZBokJ0bbVnKN4Ub5fGlMl/eNFKRzb0B1L1G2jDRBY/FRBMNSdYtl7SavLWyCgmc9RSTfZ3wxQLx1wIEc= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=yskoh@mellanox.com; Received: from yongseok-MBP.local (209.116.155.178) by VI1PR0501MB2045.eurprd05.prod.outlook.com (2603:10a6:800:36::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.18; Thu, 12 Jul 2018 18:49:27 +0000 Date: Thu, 12 Jul 2018 11:49:15 -0700 From: Yongseok Koh To: Adrien Mazarguil Cc: Shahaf Shuler , Nelio Laranjeiro , dev@dpdk.org Message-ID: <20180712184914.GB73570@yongseok-MBP.local> References: <20180627173355.4718-1-adrien.mazarguil@6wind.com> <20180627173355.4718-6-adrien.mazarguil@6wind.com> <20180712011024.GG69686@yongseok-MBP.local> <20180712104709.GU5211@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180712104709.GU5211@6wind.com> User-Agent: Mutt/1.9.3 (2018-01-21) X-Originating-IP: [209.116.155.178] X-ClientProxiedBy: BN6PR10CA0032.namprd10.prod.outlook.com (2603:10b6:404:109::18) To VI1PR0501MB2045.eurprd05.prod.outlook.com (2603:10a6:800:36::19) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 173b37c0-b0c7-4c13-1e83-08d5e8283237 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0501MB2045; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0501MB2045; 3:yUGROBPt47JzjOJCBW/lVbcQE2qKMyloEtXsRNNBPEG4YdvrozL6yqLyqpHXv+s+8Mr8ibp0AZhtF+hN5tim4lGjjiq54BQdbsxJ44ZTwr0mZXNBL83rKszQHZSzxp4A8LnGD/mz2ZoH3VxPRyp2QCM/dHe7zFuPCWpDOGdA+JObWsmTXlYpORaJprPXUFeTLvZ5xXJqpLpKrZX/FxEls9KQB/xG0r4RTkbGQCns/6CimAuxXGOP0FlhhIpiscbU; 25:DJeG79bxHpAOG/nHuqXugKuvHNbdSR+b1Mp3GCMKj+i6CC45rxd+0Fn3tENxPdx2uJ3NpciMp6V/pCumUDEY8B9yBSHP/9rUkZ6Y0Pl7H5tHPmAbHpvF4dXPsyW8fsd3lUgbbnk2VIZmS7WIQQW+yjQ5ePn7pny8KadiaN7felrV0rDZpg6Bx8Fa6hsTY4+6nkoyyZ0fIn+26FRKNXQqPnTsXQ8A5LYrxrOOyzjc1NCGyOiljWhtqABS6urekmq/ZImiX+ZumTbSZkvMZTw9IRu+9WqUmh6BG0NOkW/ZgQ88d8cx7yC2nRfifCWeuJacpyanV2A8TRBtsC3/EK1www==; 31:mQeUPDzqEKSFtiR1d97S0gIFgyJgu4X3nJa9W068SQEXqX/WD6eAiPSLQ8DjDHkAWTwuqEvacQ3XNOXwj17eJiWNTxe8m/fWpuwEKM9atzYOE2DCF2bu0LHuI3+2rWYarf7+yYzTiatstg6pp1tdrMLyYW08pvJKMHgIURfeDioNzDAymOvqugjuxHuAi+PNDI/L1qEfFM3rtos0EJ/6ZiJOYl9/1kKTTPrRpn9cshY= X-MS-TrafficTypeDiagnostic: VI1PR0501MB2045: X-LD-Processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; VI1PR0501MB2045; 20:97byd0/u8IXW6xMHvT2Ul56NLVRWfITHwnOvKiM3Pfzizy2uBjKAvDrxL7QOeXeBYNBqzUZwZENI0UXUCDEDn4M2w01gEr6effkDO3BVvdyMebUlQoZ+DBX24NTNa6UyY1Nx9MH5aUu2D8o8egFF9iP7gBdDrVThASAlOf5PtlPYkc6f23kwOs/NejiEFIWRd9ixSzB1mfXqegLLsLKB8a2uEPm4CVfiITvdQTtlk8sKxuQQrbyRzAZ2+VLeib8RKX+dD/tKCcMloTrwNai1fltmuVl8Q3lDJZM/zh79EdL0g6RRybQthF/0PekQGG8DNhVz0hLsFhgNPsFZ9PdxWqni1Tp2NctMB9uZo+QUhRZ4vUbRakFRAWx97sbqoxqI5zRacQ3Hkjz+X4n3tcuKwFT/6iKYmR5JbB2Ek7TZEp+opYWxHutEuH60Sj30Ds5V15EOxd6dgsBCTW8kUt2va95SWebf4aL3n+7iH+v67z61FwDsgo7ngbuGbKX2uucu; 4:Bt5ud/GTdxEq1aMmShtiCq4cktJ5aTF+NqykakeBx7IXcC2nUuscVFCL1r/FG/8gE78RUHjehO3JA2uIDhusJonKhfiUBEoiry2kQI5cKn08KA1zttxaxC1vLWI7vqldlyc8P9JlMJXdUiF332PXlU3ogkzUN2xv+MxFI9UVMBt4Qja+ERUQ4V2pruqUZ13wTA5R8/e6yt9S2T77jY9ZSQSwt3FAtQIVhTrQE6y9HO+ARKpQt+oLdgD5czbScJUWNRQlQ9JmaW/+yFI0okJo7A== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231311)(944501410)(52105095)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:VI1PR0501MB2045; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0501MB2045; X-Forefront-PRVS: 0731AA2DE6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39860400002)(136003)(346002)(396003)(189003)(199004)(386003)(14444005)(6506007)(97736004)(7736002)(23726003)(3846002)(6116002)(1076002)(229853002)(8936002)(305945005)(93886005)(4326008)(486006)(68736007)(47776003)(55016002)(16586007)(33656002)(81156014)(446003)(5660300001)(66066001)(6246003)(11346002)(52116002)(76176011)(86362001)(25786009)(81166006)(478600001)(476003)(58126008)(8676002)(54906003)(9686003)(53936002)(16526019)(6666003)(6916009)(2906002)(105586002)(106356001)(7696005)(98436002)(50466002)(33896004)(316002)(956004)(26005)(186003)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0501MB2045; 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; VI1PR0501MB2045; 23:wWd+kqYxigxwyuNNEfwf8gvy55oTMLbMRA1v2Y5?= =?us-ascii?Q?1ZojF7tTGVCzhOvf2lcvzZMCnbqvqiKIFPIAYnC01pIqP0Tt6bVlIdMLurLB?= =?us-ascii?Q?kwmpMgepYUf2RV7Q1+VfGXRjuGpUKVLD7XxHuExyX6yQZFFK3VKn0FNNihrR?= =?us-ascii?Q?ptk9K3OLm4Ncra7FpgoNNzcQVBGXIdr0EwT8mWK7N/oi9WQ1T/y1cC0cSSc6?= =?us-ascii?Q?KAmlY1ddr0GYr+ko2Az4Rqwdrb1pg60iF9QXafhIsBIqA/+qL2/oIZgQHHJm?= =?us-ascii?Q?zuEN4p7QYHu1A0pR8RfbSO68OHIU8MAFcyKTC3Iud7KZ4gplzXJC3dZF7+HS?= =?us-ascii?Q?tqrXPwFnLuef+P5DCinnRaWKjY94Un7nppmphXrW6b9mMmsu1KK6HTX0rJjt?= =?us-ascii?Q?eau1BiZdo50PqCnd7eD9+Z3XBhLsNJWTxfjiRfUtxzG+2pC72T6b/MNaHkhs?= =?us-ascii?Q?rg1O1evXHOL4lmkv63XMlHx808R2weae7xsq46As4PtQdoUVAEswHpbPMfUI?= =?us-ascii?Q?b9eUlrH5AvP+p4K4BaRst8VktA06lDeQhLkUJy2V15MzRaC6jYd/d7dXX12c?= =?us-ascii?Q?aASjr5t16s+zw69rkoVMC78blPHcuqZuOPerOB8SDA0Z4akfDnLaxKPQiHg/?= =?us-ascii?Q?QvVrKgeaARIz6GR5oeiAsyQIWPGp1NC3rEw9WfWOMT80qspOAIjztGvS/vdB?= =?us-ascii?Q?960Igu7QRXR0YvTS9B5yI7q2TOhIcbTqbhuE5XQ8G34xvnQD7KMA+cmfSmc8?= =?us-ascii?Q?lZuIVpw/d9qvz6KlPIkuX6Ia4SXKbuPPk8OSiqslcyPUhrIjFE7G9yYWwbyU?= =?us-ascii?Q?9l8g/3B+X60N43rPwSzCOlVfAYSdlLJP16ynjHHUje3JwuA6eYQhrxtkQJu4?= =?us-ascii?Q?N/fGSQ+G1CjomeCJYQRDVcQ0reWSrpb4o+K5sXnNkdQ6DDZfBkssxhNAlDog?= =?us-ascii?Q?bI7fpbXU2GtYpH9HekG+0II+YQlbbEfTmx/DGYwFJy705CF76w+i+f5ZuwcT?= =?us-ascii?Q?SjzSy6cAT02Zo5HFmlMr9xlv6li9nRnYT6VXZHDfRiRWT36s3HU2o4X6fAIA?= =?us-ascii?Q?W9X4utJME39thMfw1fwkYe+ZHaxBs4E9qGVznojtVslxK4+qB3Mob9PB9jAi?= =?us-ascii?Q?0VUOwgV+/q9N1wi7ZyyfEh8F+syb9Gzm6Dgyj4vTJBTrSql5kedN8qPg5opR?= =?us-ascii?Q?YA7OD8MAyJ8WvmyxjVoDG2rOjbc0VqSUaqizHlq5CVYtIMcOo2GSusxwk48r?= =?us-ascii?Q?cpoNk8PhgWKrY6bVwQiPWPDD2Km6IslYmVwhpW0irfVW8tpatnMYFZ+CVPIN?= =?us-ascii?Q?q6rogbQAXGtwo+ZBIL8YpJU8Y1KXMz8Srv4FjKUCsCpuK?= X-Microsoft-Antispam-Message-Info: SA1YvHjwsPwd8u4ADRZJ2dL/wn0grjT9cT113KDM70ZOYIuKFvKPLTfDz0/55oO4BXajHlbRgOnIPhkFVMXcKGdr7r11xVvhJeBQdHMtzn6fyiAd+b5csty6Ki/8cxnuCyeewjQtV+CkK+OTnBAZKd1846DypZMB3Vk5v+jb4zh7s0vzjiJzalMhEry01pGcBEs2ciTFDDrd6JV0htAkT5p5uC9IVbOkO/hVzS+yvuhHs8R5wSvS6rYWyymXED3j/Mj2Z8E9pv3GaK5bomMriwcY6/Dl8DsPmCZLp8SsapT3+e+PULGKHgHzZfnLN9sfAIk+YSeMYzqJK9gte1HAn5luBT0Rao7xfXYD1KJLPFs= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0501MB2045; 6:m+VLO49S28dWCxj0ZjFA+Ny2RGOCJBxeBdkID50eLMyxTHFoFBJoeaXxZUEvQviYjYYXHM9lMMLZgGXBDu+r2rtwrjryXUUXz3uINUWGjRxUGUBpW4ctZCfxivn1qLQaRuB//psBgH8zRPmkQoIzWTsAAjkR2jqqe+uRxgbcqWwKeVJPjbszoiDFlp6mzmasMZD2eUXt1KWK7w+XNtvRdyAJc+lxCogjodOFmR5ibKeK8Mv8njHA6HoUgCOmM58GvVMErQUhMvn5/9LkZf1SKJtG8CPgiQzZgKQIbp486ereO9Y+kyZWamz+nrj1xDynIgZ34aMlmrO60nFSNoK0U0PfgqlxUex5Gz6XWvSwt0dG4TJ7GXu+vCkt1bDasIML/Rj7EVORK0ijCYg/WrKILBjuNwq/UMTxG13DxnKx2RCbjdvk5E1Kuwj5SwssMAt7okBCa2SP1PMUqX8KEb2EzQ==; 5:WuCWvy6tplSmq9IjayexE0gHu8jpTNIQWAkXuyBQctg+siFESXuqpo+yAOL31Y9d0aPwGI5PQG9y2LKOAkUGQNW5Kn7o/5ycNC+V0D2IZE9jvhpvX74baTCnUwPfS2CF5vgOJp3tWCoBK1cFQOtwvitALNjo4m8ZE0rLgS28kbk=; 24:2tGN9l5GCzlbmAUvNwTiaLr312B12fpmX7abuTtGTgFve09+muhEByLCNRNiUc82KZ7X/wAW0rgHc8e6VTnQviLgWFR3WKl8lJcaZcnEBEc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR0501MB2045; 7:O6WF83Mr6CjjSSiQvxJB4UiyFQK2teeiyN9V4AFRLTkCGO4hqzABkQ2xTHJNpSBBN+5vB50QY2sTmE7IXnmKHE10nBUYj1TbEmADCpHRmbh1WbMNwycXyMiOK138Tyhd6V81LlQUkxrXWCf+132ZnTLduAdGSaA99rAPawoSxgmuOSYleoiLdj/BKpwmeSVPR7DoIYu+GnN535e1PMXO9jxlx75+tfHUY+VDkkZisGWpZW+g9EL7rYNGGBuo/yb8 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jul 2018 18:49:27.1323 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 173b37c0-b0c7-4c13-1e83-08d5e8283237 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0501MB2045 Subject: Re: [dpdk-dev] [PATCH 5/6] net/mlx5: add VLAN item and actions to switch flow rules 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: Thu, 12 Jul 2018 18:49:35 -0000 On Thu, Jul 12, 2018 at 12:47:09PM +0200, Adrien Mazarguil wrote: > On Wed, Jul 11, 2018 at 06:10:25PM -0700, Yongseok Koh wrote: > > On Wed, Jun 27, 2018 at 08:08:18PM +0200, Adrien Mazarguil wrote: > > > This enables flow rules to explicitly match VLAN traffic (VLAN pattern > > > item) and perform various operations on VLAN headers at the switch level > > > (OF_POP_VLAN, OF_PUSH_VLAN, OF_SET_VLAN_VID and OF_SET_VLAN_PCP actions). > > > > > > Testpmd examples: > > > > > > - Directing all VLAN traffic received on port ID 1 to port ID 0: > > > > > > flow create 1 ingress transfer pattern eth / vlan / end actions > > > port_id id 0 / end > > > > > > - Adding a VLAN header to IPv6 traffic received on port ID 1 and directing > > > it to port ID 0: > > > > > > flow create 1 ingress transfer pattern eth / ipv6 / end actions > > > of_push_vlan ethertype 0x8100 / of_set_vlan_vid / port_id id 0 / end > > > > > > Signed-off-by: Adrien Mazarguil > > > > @@ -681,6 +772,84 @@ mlx5_nl_flow_transpose(void *buf, > > > mnl_attr_nest_end(buf, act_index); > > > ++action; > > > break; > > > + case ACTION_OF_POP_VLAN: > > > + if (action->type != RTE_FLOW_ACTION_TYPE_OF_POP_VLAN) > > > + goto trans; > > > + conf.of_push_vlan = NULL; > > > + i = TCA_VLAN_ACT_POP; > > > + goto action_of_vlan; > > > + case ACTION_OF_PUSH_VLAN: > > > + if (action->type != RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN) > > > + goto trans; > > > + conf.of_push_vlan = action->conf; > > > + i = TCA_VLAN_ACT_PUSH; > > > + goto action_of_vlan; > > > + case ACTION_OF_SET_VLAN_VID: > > > + if (action->type != RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID) > > > + goto trans; > > > + conf.of_set_vlan_vid = action->conf; > > > + if (na_vlan_id) > > > + goto override_na_vlan_id; > > > + i = TCA_VLAN_ACT_MODIFY; > > > + goto action_of_vlan; > > > + case ACTION_OF_SET_VLAN_PCP: > > > + if (action->type != RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP) > > > + goto trans; > > > + conf.of_set_vlan_pcp = action->conf; > > > + if (na_vlan_priority) > > > + goto override_na_vlan_priority; > > > + i = TCA_VLAN_ACT_MODIFY; > > > + goto action_of_vlan; > > > +action_of_vlan: > > > + act_index = > > > + mnl_attr_nest_start_check(buf, size, act_index_cur++); > > > + if (!act_index || > > > + !mnl_attr_put_strz_check(buf, size, TCA_ACT_KIND, "vlan")) > > > + goto error_nobufs; > > > + act = mnl_attr_nest_start_check(buf, size, TCA_ACT_OPTIONS); > > > + if (!act) > > > + goto error_nobufs; > > > + if (!mnl_attr_put_check(buf, size, TCA_VLAN_PARMS, > > > + sizeof(struct tc_vlan), > > > + &(struct tc_vlan){ > > > + .action = TC_ACT_PIPE, > > > + .v_action = i, > > > + })) > > > + goto error_nobufs; > > > + if (i == TCA_VLAN_ACT_POP) { > > > + mnl_attr_nest_end(buf, act); > > > + ++action; > > > + break; > > > + } > > > + if (i == TCA_VLAN_ACT_PUSH && > > > + !mnl_attr_put_u16_check(buf, size, > > > + TCA_VLAN_PUSH_VLAN_PROTOCOL, > > > + conf.of_push_vlan->ethertype)) > > > + goto error_nobufs; > > > + na_vlan_id = mnl_nlmsg_get_payload_tail(buf); > > > + if (!mnl_attr_put_u16_check(buf, size, TCA_VLAN_PAD, 0)) > > > + goto error_nobufs; > > > + na_vlan_priority = mnl_nlmsg_get_payload_tail(buf); > > > + if (!mnl_attr_put_u8_check(buf, size, TCA_VLAN_PAD, 0)) > > > + goto error_nobufs; > > > + mnl_attr_nest_end(buf, act); > > > + mnl_attr_nest_end(buf, act_index); > > > + if (action->type == RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID) { > > > +override_na_vlan_id: > > > + na_vlan_id->nla_type = TCA_VLAN_PUSH_VLAN_ID; > > > + *(uint16_t *)mnl_attr_get_payload(na_vlan_id) = > > > + rte_be_to_cpu_16 > > > + (conf.of_set_vlan_vid->vlan_vid); > > > + } else if (action->type == > > > + RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP) { > > > +override_na_vlan_priority: > > > + na_vlan_priority->nla_type = > > > + TCA_VLAN_PUSH_VLAN_PRIORITY; > > > + *(uint8_t *)mnl_attr_get_payload(na_vlan_priority) = > > > + conf.of_set_vlan_pcp->vlan_pcp; > > > + } > > > + ++action; > > > + break; > > > > I'm wondering if there's no need to check the existence of VLAN in pattern when > > having VLAN modification actions. For example, if flow has POP_VLAN action, its > > pattern has to have VLAN item, doesn't it? > > Not necessarily. For instance there is no need to explicitly match VLAN > traffic if you somehow guarantee that only VLAN traffic goes through, > e.g. in case peer is configured to always push a VLAN header regardless, > requesting explicit match in this sense can be thought as an unnecessary > limitation. > > I agree this check would have been mandatory if this check wasn't performed > elsewhere, as discussed below: >>From user's perspective, it may not be necessary to specify VLAN in the pattern as specifying POP_VLAN action implies that. But from device/PMD perspective, there could be two options, a) complain about the violation or b) silently add VLAN pattern to not cause unexpected behavior in the device. > > Even though kernel driver has such > > validation checks, mlx5_flow_validate() can't validate it. > > Yes, note this is consistent with the rest of this particular implementation > (VLAN POP is not an exception). This entire code is a somewhat generic > rte_flow-to-TC converter which doesn't check HW capabilities at all, it > doesn't check the private structure, type of device and so on. This role is > left to the kernel implementation and (optionally) the caller function. > > The only explicit checks are performed at conversion stage; if something > cannot be converted from rte_flow to TC, as is the case for VLAN DEI (hence > the 0xefff mask). The rest is implicit, for instance I didn't bother to > implement all pattern items and fields, only the bare minimum. > > Further, ConnectX-4 and ConnectX-5 have different capabilities. The former > only supports offloading destination MAC matching and the drop action at the > switch level. Depending on driver/firmware combinations, such and such > feature may or may not be present. > > Checking everything in order to print nice error messages would have been > nice, but would have required a lot of effort. Hence the decision to > restrict the scope of this function. I worried about a case where a flow gets success from validation call but creation call returns an error (error from kernel). It would be a violation of requirement of rte_flow library. However, I agree that this implementation should have limited scope for now as the current lib/ker implementation is quite divergent. We have two separate paths to configure the flow and this should be unified. Good news is we'll get to have the unified path eventually. > > In the PRM, > > 8.18.2.7 Packet Classification Ambiguities > > ... > > In addition, a flow should not match or attempt to modify (Modify Header > > action, Pop VLAN action) non-existing fields of a packet, as defined by > > the packet classification process. > > ... > > Fortunately this code is not running on top of PRM :) > > This is my opinion anyway. If you think we need extra safety for (and only > for) VLAN POP, I'll add it, please confirm. Well, I'll leave the decision to you. Acked-by: Yongseok Koh Thanks