[dpdk-dev] [RFC 1/1] eventdev: add distributed software (DSW) event device

[Mattias Rönnblom]

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.