From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gage.eads@intel.com> Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id A65451B1C3 for <dev@dpdk.org>; Tue, 9 Jan 2018 18:00: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; 09 Jan 2018 09:00:18 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,336,1511856000"; d="scan'208,217";a="8740602" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga002.fm.intel.com with ESMTP; 09 Jan 2018 09:00:18 -0800 Received: from fmsmsx117.amr.corp.intel.com (10.18.116.17) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 9 Jan 2018 09:00:18 -0800 Received: from fmsmsx101.amr.corp.intel.com ([169.254.1.195]) by fmsmsx117.amr.corp.intel.com ([169.254.3.21]) with mapi id 14.03.0319.002; Tue, 9 Jan 2018 09:00:18 -0800 From: "Eads, Gage" <gage.eads@intel.com> To: "dev@dpdk.org" <dev@dpdk.org> CC: "jerin.jacob@caviumnetworks.com" <jerin.jacob@caviumnetworks.com>, "santosh.shukla@caviumnetworks.com" <santosh.shukla@caviumnetworks.com>, Hemant Agrawal <hemant.agrawal@nxp.com>, "nipun.gupta@nxp.com" <nipun.gupta@nxp.com>, "Van Haaren, Harry" <harry.van.haaren@intel.com>, "Richardson, Bruce" <bruce.richardson@intel.com> Thread-Topic: Documenting eventdev reconfiguration behavior Thread-Index: AdOJanQhExqctsdeQSu1MjYveb0Ryw== Date: Tue, 9 Jan 2018 17:00:16 +0000 Message-ID: <9184057F7FC11744A2107296B6B8EB1E369CE6E6@fmsmsx101.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMTkyYzAyYzItZGI4NS00NjJlLWE5NDktNzcwMjNhNzMwMjBkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IkVXcGJJMkR0QTFFbkt5ZU5DZUFOXC9HQytvVzlzNm4xZW5FR1dyZTI2TlRRPSJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.1.200.107] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [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 <dev.dpdk.org> List-Unsubscribe: <https://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Tue, 09 Jan 2018 17:00:20 -0000 Hi folks, As mentioned in a previous thread*, the eventdev documentation is unclear o= n 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 queue= d 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_confi= gure() or rte_event_queue_setup() are called? (There are probably other asp= ects that need clarification, but this is a starting point.) Hopefully we can agree on a common behavior, or else perhaps capabilities f= lags are in order. I propose we take the (in my view) simplest approach, th= at eventdevs will not preserve events when a device is stopped and restarte= d. (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? Thanks, Gage *http://dpdk.org/ml/archives/dev/2018-January/085777.html