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 28B224252B; Wed, 6 Sep 2023 21:32:16 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1A4DB402BC; Wed, 6 Sep 2023 21:32:14 +0200 (CEST) Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) by mails.dpdk.org (Postfix) with ESMTP id EF7D9402B4 for ; Wed, 6 Sep 2023 21:32:11 +0200 (CEST) Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-1c34c9cc9b9so1304885ad.3 for ; Wed, 06 Sep 2023 12:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1694028731; x=1694633531; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=hDAYGD3T1yVIOzg5JudtfkgU7Jf7mugfJepTYQ+vl38=; b=lKYmMlWmI1ATRuFsVaKglDuBTi8wSOuuSF1UooLK8YezHESJHSEqMvNQz8DfsfAqg9 Ncca5z05BZBFM1SdonxQhphcJY+DoCO3aHjGQN36K5+1XGw1kadjl5t4CuuyvxXx8PLk vpMe4QnXweik0+f6xJvyqYGoltWX/UsBQ2YoO/CGYbrKV61WgCI8r6k5rt64+m2giubp EAc5OLp++F1pocTNO5OlNriiEpv3y5/RPCzfUNSFcWTuyxZCAKz38KpIqcIbiGQiOrqt /ci9uZGx8mfZ2h8xgKcsjSK7T6CQxf+/SFKoOGoTcQwHC5Z1t7Wy68CnHOZyRYforNG/ SFnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694028731; x=1694633531; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hDAYGD3T1yVIOzg5JudtfkgU7Jf7mugfJepTYQ+vl38=; b=A/AZ9HU0U5hnUPXJ4DA+5vTzjMQiSrbniqZdkQa5om9lR2rkMW5PGl5Fw4iRWhrTZu PgCmYFwMcNjyp18uPF7VJsrglyZCVMXeAOmFHL+Lul+1DY5WWr+FwvRJ8XXrBc17GriW ok4ER5biVONfKSXeaaNnPXA4l1UPMaK4OW3BS9rODVJdD34I44GFSsbaOHLFnKfg4pzb eoSR4KU5HshZpUYJi5deVKru4CDfGHAdIDvSsyyneSbq5FFhqByymYbcsA0a1B6EqZQq 7hYIKcvDb8bcSt2n8hzHU/q/up/eriiu0pyd6kE0q0pCEhIi+dZXz8I34dimShZWDHn1 5o1A== X-Gm-Message-State: AOJu0YxmZvtf419Ms7aDNX8Nn4rfVbbOj+dUxXLiBJbV4tx3MwdaUpb+ ijNvy1WEBOGv8WBnAcqsk1eb7A== X-Google-Smtp-Source: AGHT+IFeiliE8uVH27aJg85xWpQYjQ0NXFvNR4No0UJcrvoe2Jivxy6swJL68AL7u+Z9FzuCP+9psg== X-Received: by 2002:a17:902:dad2:b0:1be:f2a1:22d8 with SMTP id q18-20020a170902dad200b001bef2a122d8mr17796258plx.14.1694028730814; Wed, 06 Sep 2023 12:32:10 -0700 (PDT) Received: from hermes.local (204-195-112-131.wavecable.com. [204.195.112.131]) by smtp.gmail.com with ESMTPSA id e7-20020a170902b78700b001c0c79b386esm11308980pls.95.2023.09.06.12.32.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Sep 2023 12:32:10 -0700 (PDT) Date: Wed, 6 Sep 2023 12:32:08 -0700 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: , Jerin Jacob , , , , 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 Subject: Re: [PATCH v3 0/3] Add dispatcher library Message-ID: <20230906123208.52109406@hermes.local> In-Reply-To: <20230904130313.327809-1-mattias.ronnblom@ericsson.com> References: <20230616074041.159675-2-mattias.ronnblom@ericsson.com> <20230904130313.327809-1-mattias.ronnblom@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 Mon, 4 Sep 2023 15:03:10 +0200 Mattias R=C3=B6nnblom 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Benchmarking indicates that the overhead is ~10 cc/event (on a > large core), with a handful of often-used handlers. >=20 > The dispatcher does not support run-time reconfiguration. >=20 > 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. 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. With DPDK, there is the additional questions about use from non-EAL threads. For the test suite, you should look at what libsystemd does.