From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id C118F1B2E8 for ; Tue, 16 Jan 2018 17:59:58 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2018 08:59:56 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,369,1511856000"; d="scan'208";a="19862982" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga003.jf.intel.com with ESMTP; 16 Jan 2018 08:59:56 -0800 Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 16 Jan 2018 08:59:55 -0800 Received: from fmsmsx108.amr.corp.intel.com ([169.254.9.65]) by FMSMSX110.amr.corp.intel.com ([169.254.14.246]) with mapi id 14.03.0319.002; Tue, 16 Jan 2018 08:59:55 -0800 From: "Eads, Gage" To: Jerin Jacob CC: "dev@dpdk.org" , "santosh.shukla@caviumnetworks.com" , Hemant Agrawal , "nipun.gupta@nxp.com" , "Van Haaren, Harry" , "Richardson, Bruce" Thread-Topic: Documenting eventdev reconfiguration behavior Thread-Index: AdOJanQhExqctsdeQSu1MjYveb0RywBhp1qAAP22AEA= Date: Tue, 16 Jan 2018 16:59:55 +0000 Message-ID: <9184057F7FC11744A2107296B6B8EB1E369DF4B2@FMSMSX108.amr.corp.intel.com> References: <9184057F7FC11744A2107296B6B8EB1E369CE6E6@fmsmsx101.amr.corp.intel.com> <20180111073009.GA8336@jerin> In-Reply-To: <20180111073009.GA8336@jerin> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMjBjMzU2YjItMzllNS00YjUxLWEwZDktOTZjMWMwNTE3YzIzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IlFyUWtPTDBJZHRLOGYwaDE1cjFlZ1BnenZBSUUrTUhwdGpWSWdqNkpFMDA9In0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.1.200.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] Documenting eventdev reconfiguration behavior 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: Tue, 16 Jan 2018 16:59:59 -0000 > -----Original Message----- > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > Sent: Thursday, January 11, 2018 1:30 AM > To: Eads, Gage > Cc: dev@dpdk.org; santosh.shukla@caviumnetworks.com; Hemant Agrawal > ; nipun.gupta@nxp.com; Van Haaren, Harry > ; Richardson, Bruce > > Subject: Re: Documenting eventdev reconfiguration behavior >=20 > -----Original Message----- > > Date: Tue, 9 Jan 2018 17:00:16 +0000 > > From: "Eads, Gage" > > To: "dev@dpdk.org" > > CC: "jerin.jacob@caviumnetworks.com" , > > "santosh.shukla@caviumnetworks.com" > > , > > Hemant Agrawal , "nipun.gupta@nxp.com" > > , "Van Haaren, Harry" > > , "Richardson, Bruce" > > > > Subject: Documenting eventdev reconfiguration behavior > > > > Hi folks, > > > > As mentioned in a previous thread*, the eventdev documentation is uncle= ar on > what the user can expect when a device is stopped, possibly re-configured= , and > restarted. The documentation states that: > > > > * If the application wants to change the configuration (i.e. call > > * rte_event_dev_configure(), rte_event_queue_setup(), or > > * rte_event_port_setup()), it must call rte_event_dev_stop() first to > > stop the > > * device and then do the reconfiguration before calling > > rte_event_dev_start() > > * again. The schedule, enqueue and dequeue functions should not be > > invoked > > * when the device is stopped. > > > > And: > > > > /** > > * Stop an event device. The device can be restarted with a call to > > * rte_event_dev_start() > > * > > * @param dev_id > > * Event device identifier. > > */ > > void > > rte_event_dev_stop(uint8_t dev_id); > > > > Specifically, the documentation is unclear on whether events that are > > queued in the device when rte_event_dev_stop() is called will remain > > there after rte_event_dev_start()? And does this depend on whether > > rte_event_dev_configure() or rte_event_queue_setup() are called? > > (There are probably other aspects that need clarification, but this is > > a starting point.) > > > > Hopefully we can agree on a common behavior, or else perhaps capabiliti= es > flags are in order. I propose we take the (in my view) simplest approach,= that > eventdevs will not preserve events when a device is stopped and restarted= . (Thus > to avoid memory leaks, the application is responsible for flushing events= out of > the device before stopping it.) This is simple to support in the sw PMD, = and I > would expect this to be simpler for hardware devices as well. > > > > Thoughts? >=20 > Currently in octeontx driver, we are flushing the events on stop(). > I agree the application should be involved in flushing the events as the = events > are opaque. > On the same time, if we application needs to flush the events, it will tr= anslate to > 1) Some sort of sync up between fastpath and control path as stop() typic= ally will > be called on control path > 2) Some HW may have separate operation for flush in addition to just call= the > dequeue() in loop >=20 > Considering the above points, How about, # Registering a callback to even= tdev, > on stop(), driver will flush the events one by one, by invoking the appli= cation > specific callback routine _and then_ call driver specific flush. >=20 > Thoughts? >=20 To reiterate, when rte_event_dev_stop() is called the eventdev will drop an= y inflight events. But before doing so it will execute a user callback fn, = which is a mechanism intended for the user to properly dispose of the infli= ght events. That seems reasonable. Since (presumably) the enqueue and dequeue functions won't be modified to r= eturn an error if called when the device is stopped (stopping an eventdev s= hould be the uncommon case, and speed is the higher priority design point t= han usability/debuggability), we should at least emphasize that any workers= that continue to enqueue/dequeue once the device is stopped will result in= undefined behavior (I'm thinking in the rte_event_dev_stop() documentation= ). If there are no counter-proposals, I'll submit a patch for this in the comi= ng weeks. Thanks! Gage