On 2018-08-27 11:40, Jerin Jacob wrote:
On 2018-07-22 13:32, Jerin Jacob wrote:
+static void
+dsw_stop(struct rte_eventdev *dev __rte_unused)
+{
You may implement, eventdev_stop_flush_t callback to free up the
outstanding events in the eventdev.
Is this support mandatory, or is it OK to leave it to the user to empty
the machinery before calling stop in the initial driver version?
This is useful to avoid event buffer leak. The application may call stop()
abruptly or some reason event device cannot provide the event on
dequeue().
I see it being useful.
I'll implement it.
Any trivial implementation could be doing dequeue() in the driver on
stop().
I can't find any other event device supporting the callback.
drivers/event/sw and drivers/event/octeontx/ supports it.
$ grep -r "dev_stop_flush" drivers/event/
drivers/event/octeontx/ssovf_evdev.c: if (dev->dev_ops->dev_stop_flush !=
NULL)
drivers/event/octeontx/ssovf_evdev.c:
dev->dev_ops->dev_stop_flush(dev->data->dev_id, event,
dev->data->dev_stop_flush_arg);
drivers/event/sw/sw_evdev_selftest.c:dev_stop_flush(struct test *t) /*
test to check we can properly flush events */
drivers/event/sw/sw_evdev_selftest.c: if
(rte_event_dev_stop_flush_callback_register(evdev, flush, &count)) {
drivers/event/sw/sw_evdev_selftest.c: if
(rte_event_dev_stop_flush_callback_register(evdev, NULL, NULL)) {
drivers/event/sw/sw_evdev_selftest.c: ret = dev_stop_flush(t);
drivers/event/sw/sw_evdev.c: eventdev_stop_flush_t flush;
drivers/event/sw/sw_evdev.c: flush = dev->dev_ops->dev_stop_flush;
drivers/event/sw/sw_evdev.c: arg = dev->data->dev_stop_flush_arg;
drivers/event/sw/sw_evdev.c: eventdev_stop_flush_t flush;
drivers/event/sw/sw_evdev.c: flush = dev->dev_ops->dev_stop_flush;
drivers/event/sw/sw_evdev.c: arg = dev->data->dev_stop_flush_arg;
I needed to rebase against master. Sorry.
In DSW, the events can be a little here-and-there - in the output
buffers, in the pause buffer, and on the input rings.
Any trivial implementation could be doing dequeue() in the driver on
stop().
Sure, but how many times? One zero-dequeue is not enough. A migration
might be in progress, and the signaling needs to finish before the
events in the pause buffer is flushed to the destination in_ring.
I'll traverse the port-internal output/pause buffers instead.
