From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: Gage Eads <gage.eads@intel.com>
Cc: dev@dpdk.org, harry.van.haaren@intel.com, hemant.agrawal@nxp.com,
bruce.richardson@intel.com, santosh.shukla@caviumnetworks.com,
nipun.gupta@nxp.com
Subject: Re: [PATCH v2 1/2] eventdev: add device stop flush callback
Date: Mon, 12 Mar 2018 11:55:28 +0530 [thread overview]
Message-ID: <20180312062527.GA20170@jerin> (raw)
In-Reply-To: <1520550631-13403-1-git-send-email-gage.eads@intel.com>
-----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 <gage.eads@intel.com>
> ---
> 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.
> struct rte_eventdev_data *data;
> /**< Pointer to device data */
> const struct rte_eventdev_ops *dev_ops;
> @@ -1822,6 +1845,34 @@ rte_event_dev_xstats_reset(uint8_t dev_id,
> */
> int rte_event_dev_selftest(uint8_t dev_id);
>
> +/**
> + * Registers a callback function to be invoked during rte_event_dev_stop() for
> + * each flushed event. This function can be used to properly dispose of queued
> + * events, for example events containing memory pointers.
> + *
> + * The callback function is only registered for the calling process. The
> + * callback function must be registered in every process that can call
> + * rte_event_dev_stop().
> + *
> + * To unregister a callback, call this function with a NULL callback pointer.
> + *
> + * @param dev_id
> + * The identifier of the device.
> + * @param callback
> + * Callback function invoked once per flushed event.
> + * @param userdata
> + * Argument supplied to callback.
> + *
> + * @return
> + * - 0 on success.
> + * - -EINVAL if *dev_id* is invalid
> + *
> + * @see rte_event_dev_stop()
> + */
> +int
> +rte_event_dev_stop_flush_callback_register(uint8_t dev_id,
> + eventdev_stop_flush_t callback, void *userdata);
> +
IMO, It would be better if we place this function near to rte_event_dev_stop().
Other than above minor changes, It looks good to me.
next prev parent reply other threads:[~2018-03-12 6:25 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-05 23:01 [PATCH 1/2] eventdev: add device stop flush callback Gage Eads
2018-03-05 23:01 ` [PATCH 2/2] event/sw: support " Gage Eads
2018-03-08 23:10 ` [PATCH v2 1/2] eventdev: add " Gage Eads
2018-03-08 23:10 ` [PATCH v2 2/2] event/sw: support " Gage Eads
2018-03-12 6:25 ` Jerin Jacob [this message]
2018-03-12 14:30 ` [PATCH v2 1/2] eventdev: add " Eads, Gage
2018-03-12 14:38 ` Jerin Jacob
2018-03-15 4:12 ` [PATCH v3 " Gage Eads
2018-03-15 4:12 ` [PATCH v3 2/2] event/sw: support " Gage Eads
2018-03-20 7:44 ` [PATCH v3 1/2] eventdev: add " Jerin Jacob
2018-03-20 14:11 ` Eads, Gage
2018-03-20 14:13 ` [PATCH v4 " Gage Eads
2018-03-20 14:13 ` [PATCH v4 2/2] event/sw: support " Gage Eads
2018-03-23 17:05 ` Van Haaren, Harry
2018-03-26 22:01 ` Eads, Gage
2018-04-02 8:03 ` Jerin Jacob
2018-04-02 15:50 ` Eads, Gage
2018-04-02 17:08 ` Jerin Jacob
2018-03-23 16:57 ` [PATCH v4 1/2] eventdev: add " Van Haaren, Harry
2018-03-26 21:59 ` Eads, Gage
2018-03-27 8:20 ` Van Haaren, Harry
2018-03-29 11:02 ` Van Haaren, Harry
2018-03-29 18:34 ` Jerin Jacob
2018-03-30 9:54 ` Liang, Ma
2018-04-02 8:01 ` Jerin Jacob
2018-04-02 18:03 ` [PATCH v5] " Gage Eads
2018-04-03 1:26 ` Jerin Jacob
2018-04-03 1:31 ` Jerin Jacob
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180312062527.GA20170@jerin \
--to=jerin.jacob@caviumnetworks.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=gage.eads@intel.com \
--cc=harry.van.haaren@intel.com \
--cc=hemant.agrawal@nxp.com \
--cc=nipun.gupta@nxp.com \
--cc=santosh.shukla@caviumnetworks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.