From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B2D65A0C41; Tue, 3 Aug 2021 10:26:35 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 38686411A7; Tue, 3 Aug 2021 10:26:35 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 525B440E32 for ; Tue, 3 Aug 2021 10:26:34 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id E52AF4001C for ; Tue, 3 Aug 2021 10:26:32 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id D0B894001A; Tue, 3 Aug 2021 10:26:32 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, AWL, NICE_REPLY_A autolearn=disabled version=3.4.2 X-Spam-Score: -1.0 Received: from [192.168.1.59] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (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 D8FAE4000E; Tue, 3 Aug 2021 10:26:31 +0200 (CEST) To: Jerin Jacob Cc: Jerin Jacob , dpdk-dev , Richard Eklycke , Liron Himi References: <2e645dd4-cb0a-d734-f570-5de7e6c58983@ericsson.com> <20210802161501.155797-1-mattias.ronnblom@ericsson.com> From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= Message-ID: <3e8c8bab-783d-d132-a836-51bd4d5533bb@ericsson.com> Date: Tue, 3 Aug 2021 10:26:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [dpdk-dev] [RFC v2 1/3] eventdev: allow for event devices requiring maintenance X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list 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 2021-08-03 06:39, Jerin Jacob wrote: > On Mon, Aug 2, 2021 at 9:45 PM Mattias Rönnblom > wrote: >> >> Extend Eventdev API to allow for event devices which require various >> forms of internal processing to happen, even when events are not >> enqueued to or dequeued from a port. >> >> RFC v2: >> - Change rte_event_maintain() return type to be consistent >> with the documentation. >> - Remove unused typedef from eventdev_pmd.h. >> >> Signed-off-by: Mattias Rönnblom >> Tested-by: Richard Eklycke >> Tested-by: Liron Himi >> --- >> lib/eventdev/rte_eventdev.h | 62 +++++++++++++++++++++++++++++++++++++ >> 1 file changed, 62 insertions(+) >> >> +/** >> + * Maintain an event device. >> + * >> + * This function is only relevant for event devices which has the >> + * RTE_EVENT_DEV_CAP_REQUIRES_MAINT flag set. Such devices requires >> + * the application to call rte_event_maintain() on a port during periods >> + * which it is neither enqueuing nor dequeuing events from this >> + * port. No port may be left unattended. >> + * >> + * An event device's rte_event_maintain() is a low overhead function. In >> + * situations when rte_event_maintain() must be called, the application >> + * should do so often. > > See rte_service_component_register() scheme, If a driver needs additional house > keeping it can use DPDK's service core scheme to abstract different driver > requirements.We may not need any public API for this. > What DSW requires, and indeed any event device that does software-level event buffering, is a way schedule the execution of some function to some time later, on the lcore that currently "owns" that port. Put differently; it's not that the driver "needs some cycles at time T", but "it needs some cycles at time T on the lcore thread that currently is the user of eventdev port X". The DSW output buffers and other per-port data structures aren't, for simplicity and performance, MT safe. That's one of the reasons the processing can't be done by a random service lcore. Pushing output buffering into the application (or whatever is accessing the event device) is not a solution to the DSW<->adapter integration issue, since DSW also requires per-port deferred work for the flow migration machinery. In addition, if you have a look at the RX adapter, for example, you'll see that the buffering logic adds complexity to the "application". The services cores are a rather course-grained deferred work construct. A more elaborate one might well have been the basis of a better solution than the proposed rte_event_maintain(), user-driven API. rte_event_maintain() is a crude way to make the Ethernet/Crypto/Timer adapters work with DSW. I would argue it still puts us in a better position than we are today, where the DSW+adapter combo doesn't work at all. If/when a more fancy DPDK deferred work framework comes along, rte_event_maintain() may be deprecated. Something like work queues in Linux could work, run as a DPDK service. In such a case, you might also need to require a service-cores-only deployment, and thus disallow the use of user-launched lcore threads. That, however, is not a couple of tiny patches.