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 92DEAA04C1; Thu, 21 Nov 2019 22:06:02 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 467F5235; Thu, 21 Nov 2019 22:06:01 +0100 (CET) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id A5F031F5 for ; Thu, 21 Nov 2019 22:05:59 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 383AD22AF2; Thu, 21 Nov 2019 16:05:57 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 21 Nov 2019 16:05:57 -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=wtV2JY+FaNh064G7DEBkFAbI0SaqOKRFhz8dyXAoVF4=; b=PnSwlM3/++w9 1zV3uVvOLLJqL9nfc9bF143Gfpw4Ectcu7Ost2sZM2OQo834ryc+VG7em3fIQzcL XSgg2TnSMPZFFf1xacYm9DfWEpIY5m7da50rgq1ala/BF5LThY59z9j5zlLQ8vzC FCiKS6f0FEChWzJPtd+SJ+dUIS1qvHM= 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=wtV2JY+FaNh064G7DEBkFAbI0SaqOKRFhz8dyXAoV F4=; b=mpwsXzv2KnYqkbC4EmTdrxQjcjgm4NvU2CdJG1/CAI77ZpwJjJbWMzFLo /kjqAXGrnDsy/7sROeOr9YCCA6rrAdAfFmtYAX4QA9tlZf5Yk6bqhUliKejLQasm oEu+Je0YvYNpeTBz4FNNfRua8vLNTQtc06LL+ojpDlpRG8k6Cf4MFRaF0231d36F Pce5pwkuG4KOhErcxODLe18DEcp+QS9Jt9f6lCAhpVHHghDCb2wV/i3AEtFlTbpa ah0vDkix4OXdDvM11zHEPLbGTDVGu6/gbZeFK1BSXpHYb4jLHZeJUnapEXM9fzqy qSX5mZ1XoL95C19Jc6Ard5mE63SGg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehvddgudegiecutefuodetggdotefrod 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 9C6CA8005B; Thu, 21 Nov 2019 16:05:54 -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 22:05:51 +0100 Message-ID: <2163387.IpHmtzr1vF@xps> In-Reply-To: <039ED4275CED7440929022BC67E7061153DCE751@SHSMSX105.ccr.corp.intel.com> References: <20191119061442.21369-1-qi.z.zhang@intel.com> <11492298.suSRLYXBfo@xps> <039ED4275CED7440929022BC67E7061153DCE751@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 13:40, Zhang, Qi Z: > From: Thomas Monjalon > > 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? > > So far, in rte_eth API, we do dev_started check at dev_configure, queue_setup (if runtime queue setup is not supported by PMD). > All other control path API is case by case depends on hardware capability. > Take i40e as an example; we have to stop the port when setting MTU because we have to reconfigure the hardware queue context, which needs to stop queue that impacts data path. > While for VLAN / promiscuous, since it is the case that a rule is added into the on-chip memory, so no need to stop the data path. > > Maybe it's a good idea to define a rule that which control path is allowed at runtime, which should not be. > But at least I think it's not necessary to prevent users from doing flow configure at runtime.; Yes I agree. Based on the list of allowed runtime config changes, we could think about a global solution to allow datapath optimization taking application needs into account.