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 122F1A04C1; Thu, 21 Nov 2019 13:40:55 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E509E2BA8; Thu, 21 Nov 2019 13:40:54 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id A9D5B2BA2 for ; Thu, 21 Nov 2019 13:40:53 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Nov 2019 04:40:52 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,224,1571727600"; d="scan'208";a="232291018" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga004.fm.intel.com with ESMTP; 21 Nov 2019 04:40:52 -0800 Received: from fmsmsx157.amr.corp.intel.com (10.18.116.73) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 21 Nov 2019 04:40:51 -0800 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by FMSMSX157.amr.corp.intel.com (10.18.116.73) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 21 Nov 2019 04:40:51 -0800 Received: from shsmsx105.ccr.corp.intel.com ([169.254.11.225]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.213]) with mapi id 14.03.0439.000; Thu, 21 Nov 2019 20:40:49 +0800 From: "Zhang, Qi Z" To: Thomas Monjalon CC: "dev@dpdk.org" , "Ye, Xiaolong" , "Yigit, Ferruh" , "arybchenko@solarflare.com" , "orika@mellanox.com" Thread-Topic: [dpdk-dev] [PATCH v4] net/ice: add flow mark hint support Thread-Index: AQHVnqBEvrWfRlZogEKSmQzsdRLUU6eT5RmAgADbnND///i2gIAAx38g Date: Thu, 21 Nov 2019 12:40:48 +0000 Message-ID: <039ED4275CED7440929022BC67E7061153DCE751@SHSMSX105.ccr.corp.intel.com> References: <20191119061442.21369-1-qi.z.zhang@intel.com> <2166340.TqaS7Hc55D@xps> <039ED4275CED7440929022BC67E7061153DCE1E6@SHSMSX105.ccr.corp.intel.com> <11492298.suSRLYXBfo@xps> In-Reply-To: <11492298.suSRLYXBfo@xps> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTFmZWJkYzgtZWNjOC00YzlhLTk2MTgtMTFiZDE4N2VmMzczIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoia3Z5MmZxakhORHc3QnFGeEJ1VG1yVnJuXC9BciszaXpGZ01PVTZwRndpK3RJcjBKeHN5NUhJRGwzVkdMYnRFNGoifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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" > -----Original Message----- > From: Thomas Monjalon > Sent: Thursday, November 21, 2019 3:37 PM > To: Zhang, Qi Z > Cc: dev@dpdk.org; Ye, Xiaolong ; Yigit, Ferruh > ; arybchenko@solarflare.com; orika@mellanox.com > Subject: Re: [dpdk-dev] [PATCH v4] net/ice: add flow mark hint support >=20 > 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 >=20 > OK so you confirm the problem is only when a configuration is changed at > runtime without stopping the port. >=20 > > Also this option is overwhelmed by option 1 if we plan to do a clean fi= x in > driver. >=20 > 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. >=20 > 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_set= up (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 queu= e that impacts data path. While for VLAN / promiscuous, since it is the case that a rule is added int= o the on-chip memory, so no need to stop the data path. =20 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 co= nfigure at runtime.; >=20