From mboxrd@z Thu Jan 1 00:00:00 1970 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) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id E23C54002C; Mon, 27 Aug 2018 12:24:04 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.4.1 X-Spam-Score: -0.4 Received: from [192.168.1.122] (host-90-232-97-171.mobileonline.telia.com [90.232.97.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 053454002A; Mon, 27 Aug 2018 12:24:03 +0200 (CEST) To: Jerin Jacob Cc: dev@dpdk.org, bruce.richardson@intel.com References: <20180711210844.5467-1-mattias.ronnblom@ericsson.com> <20180711210844.5467-2-mattias.ronnblom@ericsson.com> <20180722113254.GA30026@jerin> <20180827094001.GA22264@jerin> From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= Message-ID: <149d3d33-8a54-715c-25f9-24612cc60d56@ericsson.com> Date: Mon, 27 Aug 2018 12:24:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180827094001.GA22264@jerin> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [dpdk-dev] [RFC 1/1] eventdev: add distributed software (DSW) event device X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 10:24:05 -0000 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.