From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= Subject: Re: [RFC 1/1] eventdev: add distributed software (DSW) event device Date: Mon, 27 Aug 2018 12:24:02 +0200 Message-ID: <149d3d33-8a54-715c-25f9-24612cc60d56@ericsson.com> References: <20180711210844.5467-1-mattias.ronnblom@ericsson.com> <20180711210844.5467-2-mattias.ronnblom@ericsson.com> <20180722113254.GA30026@jerin> <20180827094001.GA22264@jerin> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, bruce.richardson@intel.com To: Jerin Jacob Return-path: Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by dpdk.org (Postfix) with ESMTP id 785924CA7 for ; Mon, 27 Aug 2018 12:24:05 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id F1F4840030 for ; Mon, 27 Aug 2018 12:24:04 +0200 (CEST) In-Reply-To: <20180827094001.GA22264@jerin> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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.