From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [PATCH v2 1/2] eventdev: add device stop flush callback Date: Mon, 12 Mar 2018 20:08:23 +0530 Message-ID: <20180312143822.GA3636@jerin> References: <1520290870-4987-1-git-send-email-gage.eads@intel.com> <1520550631-13403-1-git-send-email-gage.eads@intel.com> <20180312062527.GA20170@jerin> <9184057F7FC11744A2107296B6B8EB1E3FA711B8@FMSMSX108.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "dev@dpdk.org" , "Van Haaren, Harry" , "hemant.agrawal@nxp.com" , "Richardson, Bruce" , "santosh.shukla@caviumnetworks.com" , "nipun.gupta@nxp.com" To: "Eads, Gage" Return-path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0077.outbound.protection.outlook.com [104.47.32.77]) by dpdk.org (Postfix) with ESMTP id 293EF5F1F for ; Mon, 12 Mar 2018 15:38:48 +0100 (CET) Content-Disposition: inline In-Reply-To: <9184057F7FC11744A2107296B6B8EB1E3FA711B8@FMSMSX108.amr.corp.intel.com> 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----- > Date: Mon, 12 Mar 2018 14:30:49 +0000 > From: "Eads, Gage" > To: Jerin Jacob > CC: "dev@dpdk.org" , "Van Haaren, Harry" > , "hemant.agrawal@nxp.com" > , "Richardson, Bruce" > , "santosh.shukla@caviumnetworks.com" > , "nipun.gupta@nxp.com" > > Subject: RE: [PATCH v2 1/2] eventdev: add device stop flush callback > > > > > -----Original Message----- > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > Sent: Monday, March 12, 2018 1:25 AM > > To: Eads, Gage > > Cc: dev@dpdk.org; Van Haaren, Harry ; > > hemant.agrawal@nxp.com; Richardson, Bruce ; > > santosh.shukla@caviumnetworks.com; nipun.gupta@nxp.com > > Subject: Re: [PATCH v2 1/2] eventdev: add device stop flush callback > > > > -----Original Message----- > > > When an event device is stopped, it drains all event queues. These > > > events may contain pointers, so to prevent memory leaks eventdev now > > > supports a user-provided flush callback that is called during the queue drain > > process. > > > This callback is stored in process memory, so the callback must be > > > registered by any process that may call rte_event_dev_stop(). > > > > > > This commit also clarifies the behavior of rte_event_dev_stop(). > > > > > > This follows this mailing list discussion: > > > http://dpdk.org/ml/archives/dev/2018-January/087484.html > > > > > > Signed-off-by: Gage Eads > > > --- > > > v2: allow a NULL callback pointer to unregister the callback > > > > > > lib/librte_eventdev/rte_eventdev.c | 17 +++++++++ > > > lib/librte_eventdev/rte_eventdev.h | 55 > > +++++++++++++++++++++++++++- > > > lib/librte_eventdev/rte_eventdev_version.map | 6 +++ > > > 3 files changed, 76 insertions(+), 2 deletions(-) > > > > > > diff --git a/lib/librte_eventdev/rte_eventdev.c > > > b/lib/librte_eventdev/rte_eventdev.c > > > index 851a119..1aacb7b 100644 > > > --- a/lib/librte_eventdev/rte_eventdev.c > > > +++ b/lib/librte_eventdev/rte_eventdev.c > > > @@ -1123,6 +1123,23 @@ rte_event_dev_start(uint8_t dev_id) > > > return 0; > > > } > > > > > > +typedef void (*eventdev_stop_flush_t)(uint8_t dev_id, struct rte_event event, > > > + void *arg); > > > +/**< Callback function called during rte_event_dev_stop(), invoked > > > +once per > > > + * flushed event. > > > + */ > > > + > > > #define RTE_EVENTDEV_NAME_MAX_LEN (64) > > > /**< @internal Max length of name of event PMD */ > > > > > > @@ -1176,6 +1194,11 @@ struct rte_eventdev { > > > event_dequeue_burst_t dequeue_burst; > > > /**< Pointer to PMD dequeue burst function. */ > > > > > > + eventdev_stop_flush_t dev_stop_flush; > > > + /**< Optional, user-provided event flush function */ > > > + void *dev_stop_flush_arg; > > > + /**< User-provided argument for event flush function */ > > > + > > > > I think, we can move this additions to the internal rte_eventdev_data structure. > > Reasons are > > 1) Changes to "struct rte_eventdev" would call for ABI change > > 2) We can keep "struct rte_eventdev" only for fast path functions, slow path > > functions can have additional redirection. > > > > Good points -- I hadn't considered the ABI impact of modifying rte_eventdev. rte_eventdev_data is in shared memory, though, so it's not multi-process friendly for function pointers. How about putting it in rte_eventdev_ops? Yes. Make sense to move to rte_eventdev_ops. But need to take care updating the those function pointers in secondary process.