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 EF4CD4252C; Wed, 6 Sep 2023 22:28:32 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 867C0402A9; Wed, 6 Sep 2023 22:28:32 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id D61504027E; Wed, 6 Sep 2023 22:28:30 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 81BC41980D; Wed, 6 Sep 2023 22:28:30 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 8019419796; Wed, 6 Sep 2023 22:28:30 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, AWL, NICE_REPLY_A autolearn=disabled version=3.4.6 X-Spam-Score: -2.3 Received: from [192.168.1.59] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 8F8021974B; Wed, 6 Sep 2023 22:28:29 +0200 (CEST) Message-ID: <8d259536-de0d-1f95-76f7-4d5c9e953b83@lysator.liu.se> Date: Wed, 6 Sep 2023 22:28:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: [PATCH v3 0/3] Add dispatcher library Content-Language: en-US To: Stephen Hemminger , =?UTF-8?Q?Mattias_R=c3=b6nnblom?= Cc: dev@dpdk.org, Jerin Jacob , techboard@dpdk.org, harry.van.haaren@intel.com, Peter Nilsson , Heng Wang , Naga Harish K S V , Pavan Nikhilesh , Gujjar Abhinandan S , Erik Gabriel Carrillo , Shijith Thotton , Hemant Agrawal , Sachin Saxena , Liang Ma , Peter Mccarthy , Zhirun Yan References: <20230616074041.159675-2-mattias.ronnblom@ericsson.com> <20230904130313.327809-1-mattias.ronnblom@ericsson.com> <20230906123208.52109406@hermes.local> From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= In-Reply-To: <20230906123208.52109406@hermes.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP 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 On 2023-09-06 21:32, Stephen Hemminger wrote: > On Mon, 4 Sep 2023 15:03:10 +0200 > Mattias Rönnblom wrote: > >> The purpose of the dispatcher library is to decouple different parts >> of an eventdev-based application (e.g., processing pipeline stages), >> sharing the same underlying event device. >> >> The dispatcher replaces the conditional logic (often, a switch >> statement) that typically follows an event device dequeue operation, >> where events are dispatched to different parts of the application >> based on event meta data, such as the queue id or scheduling type. >> >> The concept is similar to a UNIX file descriptor event loop library. >> Instead of tying callback functions to fds as for example libevent >> does, the dispatcher relies on application-supplied matching callback >> functions to decide where to deliver events. >> >> A dispatcher is configured to dequeue events from a specific event >> device, and ties into the service core framework, to do its (and the >> application's) work. >> >> The dispatcher provides a convenient way for an eventdev-based >> application to use service cores for application-level processing, and >> thus for sharing those cores with other DPDK services. >> >> Although the dispatcher adds some overhead, experience suggests that >> the net effect on the application (both synthetic benchmarks and more >> real-world applications) may well be positive. This is primarily due >> to clustering (see programming guide) reducing cache misses. >> >> Benchmarking indicates that the overhead is ~10 cc/event (on a >> large core), with a handful of often-used handlers. >> >> The dispatcher does not support run-time reconfiguration. >> >> The use of the dispatcher library is optional, and an eventdev-based >> application may still opt to access the event device using direct >> eventdev API calls, or by some other means. > > My experience with event libraries is mixed. > There are already multiple choices libevent, libev, and libsystemd as > well as rte_epoll(). Not sure if adding another one is helpful. > This library *conceptually* provides the same kind of functionality as libevent, but has nothing to do with file descriptor events. These are eventdev events, and thus are tied to the arrival of a packet, a notification some kind of hardware offload, a timeout, or something else DPDK PMD-related. > The main issue is dealing with external (non DPDK) events which usually > are handled as file descriptors (signalfd, epoll, etc). The other issue > is the thread safety. Most event libraries are not thread safe which > makes handling one event waking up another difficult. > This machinery is for use exclusively by EAL threads, for fast-path packet processing. No syscalls, no non-DPDK events. > With DPDK, there is the additional questions about use from non-EAL threads. > See above. > For the test suite, you should look at what libsystemd does. >