From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 864F9A0C45; Tue, 19 Oct 2021 03:00:50 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0D42640142; Tue, 19 Oct 2021 03:00:50 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mails.dpdk.org (Postfix) with ESMTP id E22234003E for ; Tue, 19 Oct 2021 03:00:47 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10141"; a="208500808" X-IronPort-AV: E=Sophos;i="5.85,382,1624345200"; d="scan'208";a="208500808" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Oct 2021 18:00:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,382,1624345200"; d="scan'208";a="483007750" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by orsmga007.jf.intel.com with ESMTP; 18 Oct 2021 18:00:45 -0700 Received: from shsmsx606.ccr.corp.intel.com (10.109.6.216) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Mon, 18 Oct 2021 18:00:44 -0700 Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by SHSMSX606.ccr.corp.intel.com (10.109.6.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Tue, 19 Oct 2021 09:00:42 +0800 Received: from shsmsx601.ccr.corp.intel.com ([10.109.6.141]) by SHSMSX601.ccr.corp.intel.com ([10.109.6.141]) with mapi id 15.01.2242.012; Tue, 19 Oct 2021 09:00:42 +0800 From: "Zhang, Qi Z" To: Dmitry Kozlyuk , "dev@dpdk.org" CC: Ori Kam , NBU-Contact-Thomas Monjalon , "Yigit, Ferruh" , "Andrew Rybchenko" Thread-Topic: [dpdk-dev] [PATCH v2 1/5] ethdev: add capability to keep flow rules on restart Thread-Index: AQHXweBjxFZmFHxTbU2xsDnRzDRAjqvYt1uwgAAkEICAAJ8cAA== Date: Tue, 19 Oct 2021 01:00:42 +0000 Message-ID: <0c91e1ed69d447788465633d70e7eb8a@intel.com> References: <20211005005216.2427489-1-dkozlyuk@nvidia.com> <20211015161822.3099818-1-dkozlyuk@nvidia.com> <20211015161822.3099818-2-dkozlyuk@nvidia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.6.200.16 dlp-product: dlpe-windows x-originating-ip: [10.239.127.36] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 1/5] ethdev: add capability to keep flow rules on restart X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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: Dmitry Kozlyuk > Sent: Tuesday, October 19, 2021 6:51 AM > To: Zhang, Qi Z ; dev@dpdk.org > Cc: Ori Kam ; NBU-Contact-Thomas Monjalon > ; Yigit, Ferruh ; Andrew > Rybchenko > Subject: RE: [dpdk-dev] [PATCH v2 1/5] ethdev: add capability to keep flo= w > rules on restart >=20 > > -----Original Message----- > > From: Zhang, Qi Z > > Sent: 18 =CF=CB=D4=D1=C2=D2=D1 2021 =C7. 16:06 > > To: Dmitry Kozlyuk ; dev@dpdk.org > > Cc: Ori Kam ; NBU-Contact-Thomas Monjalon > > ; Yigit, Ferruh ; Andrew > > Rybchenko > > Subject: RE: [dpdk-dev] [PATCH v2 1/5] ethdev: add capability to keep > > flow rules on restart > > > > External email: Use caution opening links or attachments > > > > > > > -----Original Message----- > > > From: dev On Behalf Of Dmitry Kozlyuk > > > Sent: Saturday, October 16, 2021 12:18 AM > > > To: dev@dpdk.org > > > Cc: Ori Kam ; Thomas Monjalon > > > ; Yigit, Ferruh ; > > > Andrew Rybchenko > > > Subject: [dpdk-dev] [PATCH v2 1/5] ethdev: add capability to keep > > > flow > > rules > > > on restart > > > > > > Currently, it is not specified what happens to the flow rules when > > > the > > device is > > > stopped, possibly reconfigured, then started. > > > If flow rules were kept, it could be convenient for application > > developers, > > > because they wouldn't need to save and restore them. > > > However, due to the number of flows and possible creation rate it is > > > impractical to save all flow rules in DPDK layer. This means that > > > flow > > rules > > > persistence really depends on whether PMD and HW can implement it > > > efficiently. It can also be limited by the rule item and action > > > types, > > and its > > > attributes transfer bit, which together comprise the rule kind. > > > > > > Add a device capability bit for PMDs that can keep at least some of > > > the > > flow > > > rules across restart. Without this capability behavior is still > > unspecified, which > > > is now explicitly stated. > > > Declare that the application can test for persitence of flow rules > > > of a > > particular > > > kind by attempting to create a rule of that kind when the device is > > stopped > > > and checking for the specific error. > > > This is logical because if the PMD can to create the flow rule when > > > the > > device > > > is not started and use it after the start happens, it is natural > > > that it > > can move > > > its internal flow rule object to the same state when the device is > > stopped and > > > restore the state when the device is started. > > > > > > If the device is being reconfigured in a way that is incompatible > > > with > > existing > > > flow rules, PMD is required to report an error. > > > This is mandatory, because flow API does not supply users with > > capabilities, so > > > this is the only way for a user to learn that configuration is invali= d. > > > > What if a PMD does not flush rules during start /stop cycle, but just > > want to simply flush rules during dev_config? > > Is it reasonable to take above as an typical implementation to avoid > > all the complexity for handling the conflicts? > > > > 1. queues are destroyed and re-created with a different number which > > may impact "to queue" action. > > 2. hash key may be overwritten which impact RSS result. > > 3. offload flags changes may impact data path selection which cause > > mark action does not work. > > .... >=20 > Hello Qi, >=20 > Yes, it sounds reasonable that rules do need not to persist across > reconfiguration. > Unlike indirect actions, they are too numerous for PMD to track and check= . > I'm not sure rte_eth_dev_configure() should be specified to implicitly fl= ush > them. > Some PMDs may wish to preserve the rules even then in the future, so we > don't want applications to rely on configure flushing the rules. > It can be specified that applications should flush the rules themselves b= efore. OK, I'm trying to figure out how to set this "keep" capability for a PMD th= at don't want application to re-create rules after dev_stop, but still want= rules be flushed before reconfigure. I think the answer is it should expose the "keep" capability and simply ret= urn error in dev_configure if any rules exists, thanks