From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E560CA04C1; Thu, 21 Nov 2019 08:36:38 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B2D802BA2; Thu, 21 Nov 2019 08:36:37 +0100 (CET) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id E4EEC271 for ; Thu, 21 Nov 2019 08:36:35 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0EBAA220F8; Thu, 21 Nov 2019 02:36:35 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 21 Nov 2019 02:36:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=ejfMXLth1nMopWlfWdh/wxfp59Yy0h7s4ughRVy+5v4=; b=EOSQEskiHwvJ kIZxdSnVi5iCOfpiJ6weLkO4t0J+bdGwSIMlN3wLhsZz9g6eoiCPS3E0ulze+4P0 R7b7/oGP+0lYYoZhOI0SdJAzWwp3EVhRhct0xvqYhZmkfeKEJ2+OL7C98tZz9LQp 1unqTn+go3IBgahvzfyRHYikCBW9X2A= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=ejfMXLth1nMopWlfWdh/wxfp59Yy0h7s4ughRVy+5 v4=; b=xJSYsm5iQt52NIDB0GAyWopUvoUxZcOtJ97pwlDZv/5HVkazFILlg5hwP 63Jeb8uzzSn78f5tpHOd1+3O1rQY3Is8otS/HBCWsY3qJbFLcTTHuLL2P8M7ISMb X/MR4Ek1u9esYcJSJSe2WTsHCq7EdbfbRJS49sJcxct9Q6Yadp/U0V6dq2ANbNbk CtBSVsGusG+RjBQaqYGlojQAiGEJdy3N4iMKi7Ea3qOnmYoCswvJzMIOkQT+LWzp LlcLbfo+ksi9ivP98VQIiRTHRWrPE1ZM1/5zyD6aMxITzkfI7nGqmcBbQ/UxPRij uXzLtULUQ8xDMBltHGgbsfdlTdvuw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehuddguddtlecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc fkphepjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpeht hhhomhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 8BA8C306005C; Thu, 21 Nov 2019 02:36:33 -0500 (EST) From: Thomas Monjalon To: "Zhang, Qi Z" Cc: dev@dpdk.org, "Ye, Xiaolong" , "Yigit, Ferruh" , "arybchenko@solarflare.com" , "orika@mellanox.com" Date: Thu, 21 Nov 2019 08:36:31 +0100 Message-ID: <11492298.suSRLYXBfo@xps> In-Reply-To: <039ED4275CED7440929022BC67E7061153DCE1E6@SHSMSX105.ccr.corp.intel.com> References: <20191119061442.21369-1-qi.z.zhang@intel.com> <2166340.TqaS7Hc55D@xps> <039ED4275CED7440929022BC67E7061153DCE1E6@SHSMSX105.ccr.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v4] net/ice: add flow mark hint support 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" 21/11/2019 02:19, Zhang, Qi Z: > From: Thomas Monjalon > > 19/11/2019 07:14, Qi Zhang: > > > Since not all data paths support flow mark, the driver needs a hint > > > from application to select the correct data path if flow mark is > > > required. The patch introduces a devarg "flow-mark-support" as a > > > workaround solution, since a standard way is still ongoing. > > > > > > Signed-off-by: Qi Zhang > > > Acked-by: Qiming Yang > > > --- > > > +- ``Flow Mark Support`` (default ``0``) > > > + > > > + This is a hint to the driver to select the data path that supports > > > + flow mark extraction by default. > > > + NOTE: This is an experimental devarg, it will be removed when any > > > + of below conditions is ready. > > > + 1) all data paths support flow mark (currently vPMD does not) > > > + 2) a new offload like RTE_DEV_RX_OFFLOAD_FLOW_MARK be introduced > > as a standard way to hint. > > > > When the data path is selected? > > dev_start > > > I suppose such decision should be done when starting the port, after everything > > is configured. > > So you can check if a rte_flow rule was added for mark action. > > Why the user needs to use an explicit option? > > A rte_flow with mark can be issued at any time after dev_start when it is need, in that case, we have to reject the flow, this has been complained a lot base on previous feedback by users, since inconsistent behavior (sometimes mark works, some time it does not) is not expected OK so you confirm the problem is only when a configuration is changed at runtime without stopping the port. > Also this option is overwhelmed by option 1 if we plan to do a clean fix in driver. You want the application (or the user) to announce in advance which configuration could be applied during the runtime. I think we should consider the problem for any runtime configuration. We never clearly defined which configuration is allowed at runtime. Which other configs may be setup at runtime? MTU? VLAN? mirroring? tunneling checksum? promiscuous? supported packet types? IEEE1588?