From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id B2FF944C3 for ; Sun, 14 Jan 2018 03:03:19 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jan 2018 18:03:18 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,356,1511856000"; d="scan'208";a="10212536" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by fmsmga002.fm.intel.com with ESMTP; 13 Jan 2018 18:03:18 -0800 Received: from fmsmsx125.amr.corp.intel.com (10.18.125.40) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sat, 13 Jan 2018 18:03:18 -0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by FMSMSX125.amr.corp.intel.com (10.18.125.40) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sat, 13 Jan 2018 18:03:18 -0800 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.213]) by shsmsx102.ccr.corp.intel.com ([169.254.2.189]) with mapi id 14.03.0319.002; Sun, 14 Jan 2018 10:03:15 +0800 From: "Zhang, Qi Z" To: "Wiles, Keith" , Alex Rosenbaum CC: "adrien.mazarguil@6wind.com" , DPDK , "Doherty, Declan" Thread-Topic: [dpdk-dev] [RFC v2 3/5] ether: Add flow timeout support Thread-Index: AQHTekBqIxF5BGkBL0qvYqgGLIKxeaNNTSkAgAG6IXD//9oiAIAj3xMg Date: Sun, 14 Jan 2018 02:03:14 +0000 Message-ID: <039ED4275CED7440929022BC67E706115312D465@SHSMSX103.ccr.corp.intel.com> References: <1513823719-36066-1-git-send-email-qi.z.zhang@intel.com> <1513823719-36066-4-git-send-email-qi.z.zhang@intel.com> <039ED4275CED7440929022BC67E7061153124111@SHSMSX103.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.0.116 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] [RFC v2 3/5] ether: Add flow timeout 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: , X-List-Received-Date: Sun, 14 Jan 2018 02:03:20 -0000 Hi Alex & Keith =09 Base on my further understanding about OVS requirement and the new device'= s capability. I realize there is no strong point to have the timeout APIs from this patc= h, I'd like to withdraw it. Thanks for all your comments that help me to think it over. Regards Qi > -----Original Message----- > From: Wiles, Keith > Sent: Friday, December 22, 2017 10:06 PM > To: Zhang, Qi Z > Cc: Alex Rosenbaum ; > adrien.mazarguil@6wind.com; DPDK ; Doherty, Declan > > Subject: Re: [dpdk-dev] [RFC v2 3/5] ether: Add flow timeout support >=20 >=20 >=20 > > On Dec 22, 2017, at 3:03 AM, Zhang, Qi Z wrote: > > > > Alex: > > > >> -----Original Message----- > >> From: Alex Rosenbaum [mailto:rosenbaumalex@gmail.com] > >> Sent: Thursday, December 21, 2017 9:59 PM > >> To: Zhang, Qi Z > >> Cc: adrien.mazarguil@6wind.com; DPDK ; Doherty, Declan > >> > >> Subject: Re: [dpdk-dev] [RFC v2 3/5] ether: Add flow timeout support > >> > >> On Thu, Dec 21, 2017 at 4:35 AM, Qi Zhang wrote= : > >>> Add new APIs to support flow timeout, application is able to 1. > >>> Setup the time duration of a flow, the flow is expected to be > >>> deleted automatically when timeout. > >> > >> Can you explain how the application (OVS) is expected to use this API? > >> It will help to better understand the motivation here... > > > > I think the purpose of the APIs is to expose the hardware feature that > > support flow auto delete with a timeout. > > As I know, for OVS, every flow in flow table will have time duration A > > flow be offloaded to hardware is still required to be deleted in > > specific time, I think these APIs help OVS to take advantage HW > > feature and simplify the flow aging management > > > >> > >> Are you trying to move the aging timer from application code into the = PMD? > >> or can your HW remove/disable/inactivate a flow at certain time > >> semantics without software context? > > > > Yes, it for hardware feature. >=20 > We also need to support a software timeout feature here and not just a > hardware one. The reason is to make the APIs consistent across all hardwa= re. If > you are going to include hardware timeout then we need to add software > supported timeout at the same time IMO. >=20 > > > >> > >> I would prefer to have the aging timer logic in a centralized > >> location, leek the application itself or some DPDK library. instead > >> of having each PMD implement its own software timers. > >> > >> > >>> 3. Register a callback function when a flow is deleted due to timeout= . > >> > >> Is the application 'struct rte_flow*' handle really deleted? or the > >> flow was removed from HW, just in-active at this time? > > > > Here the flow is deleted, same thing happen as rte_flow_destroy and we > > need to call rte_flow_create to re-enable the flow. > > I will add more explanation to avoid confusion in next release. >=20 > Sorry, I little late into this thread, but we can not have 1000 callbacks= for each > timeout and we need make sure we bunch up a number of timeouts at a time = to > make the feature more performant IMO. Maybe that discussed or address in > the code. >=20 > > > >> > >> Can a flow be re-activated? or does this require a call to > >> rte_flow_destory() and ret_flow_create()? > >> > >> Alex > > > > Thanks > > Qi >=20 > Regards, > Keith