From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 7481A1B37C for ; Fri, 22 Dec 2017 15:06:13 +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 fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Dec 2017 06:06:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,441,1508828400"; d="scan'208";a="4043793" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga002.fm.intel.com with ESMTP; 22 Dec 2017 06:06:12 -0800 Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 22 Dec 2017 06:06:12 -0800 Received: from fmsmsx117.amr.corp.intel.com ([169.254.3.21]) by FMSMSX155.amr.corp.intel.com ([169.254.5.8]) with mapi id 14.03.0319.002; Fri, 22 Dec 2017 06:06:11 -0800 From: "Wiles, Keith" To: "Zhang, Qi Z" CC: Alex Rosenbaum , "adrien.mazarguil@6wind.com" , DPDK , "Doherty, Declan" Thread-Topic: [dpdk-dev] [RFC v2 3/5] ether: Add flow timeout support Thread-Index: AQHTekB/67KI3OniD0KpQ8rW2/rZnqNOWWIAgAE/xQCAAFR9AA== Date: Fri, 22 Dec 2017 14:06:10 +0000 Message-ID: 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: <039ED4275CED7440929022BC67E7061153124111@SHSMSX103.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.0.10] Content-Type: text/plain; charset="us-ascii" Content-ID: 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: Fri, 22 Dec 2017 14:06:13 -0000 > On Dec 22, 2017, at 3:03 AM, Zhang, Qi Z wrote: >=20 > Alex: >=20 >> -----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 >>=20 >> 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. >>=20 >> Can you explain how the application (OVS) is expected to use this API? >> It will help to better understand the motivation here... >=20 > I think the purpose of the APIs is to expose the hardware feature that su= pport > 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 specif= ic time,=20 > I think these APIs help OVS to take advantage HW feature and simplify the= flow > aging management >=20 >>=20 >> Are you trying to move the aging timer from application code into the PM= D? >> or can your HW remove/disable/inactivate a flow at certain time semantic= s >> without software context? >=20 > Yes, it for hardware feature. We also need to support a software timeout feature here and not just a hard= ware one. The reason is to make the APIs consistent across all hardware. If= you are going to include hardware timeout then we need to add software sup= ported timeout at the same time IMO. >=20 >>=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. >>=20 >>=20 >>> 3. Register a callback function when a flow is deleted due to timeout. >>=20 >> Is the application 'struct rte_flow*' handle really deleted? or the flow= was >> removed from HW, just in-active at this time? >=20 > Here the flow is deleted, same thing happen as rte_flow_destroy and we ne= ed to call > rte_flow_create to re-enable the flow.=20 > I will add more explanation to avoid confusion in next release. Sorry, I little late into this thread, but we can not have 1000 callbacks f= or 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 addr= ess in the code. >=20 >>=20 >> Can a flow be re-activated? or does this require a call to >> rte_flow_destory() and ret_flow_create()? >>=20 >> Alex >=20 > Thanks > Qi Regards, Keith