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 6A356426D4; Fri, 6 Oct 2023 18:03:12 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0DF44402C8; Fri, 6 Oct 2023 18:03:12 +0200 (CEST) Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by mails.dpdk.org (Postfix) with ESMTP id D21F9402B9 for ; Fri, 6 Oct 2023 18:03:10 +0200 (CEST) Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-1c5c91bec75so17998565ad.3 for ; Fri, 06 Oct 2023 09:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1696608190; x=1697212990; 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=bP3b1NOB+WQHg0RjoOM/9Ly55dYQWDDpM4+XXtbxZSc=; b=RUlUorfjvnqkRzKEFoWUuQM/REjiDAKfKQrngPUevI+wqWruu3Bd2XZ27+ZXtDl4Qv T7y+As/pevfRadEwypOmj9LdEklhWWcmksef7x3VFrEfb/cZiLbEgw2zm4Hjs0X0yCJi 0Zuhmm6s9dCLkPCmpPyRP1y1InmHgm2vVaMWAfNFDH9Yw6lofEKQGzrZewZ1mkmE+2sA eFcpvq+q6K1NPFDxB2lhI2yh/B7fHJGDsWFVs89ryQFm9bd1x9Qjmjum4+9fzZD6sM39 AN3z1St2qMcOnOqzEMh5RUeQIqBO8ik0QDe2VPSYjBfHap63wLyi9gSyPCdsNuwh399F zEVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696608190; x=1697212990; 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=bP3b1NOB+WQHg0RjoOM/9Ly55dYQWDDpM4+XXtbxZSc=; b=EfitMbbaIvwDC27OCeUkT4K1tlrTlKIinwpV+VNuHnQDmSH1cSjnH55T8U5t9wvrzT POi0M6CYYqhid+4jvcpeLw/DZCGQnhIctryzNgwj7idWhNNe9Dx/S8g9pdGBLHhskDe1 kGdlr/L60U1+CvWVjHEPCmU4CMCesZDGxOw3lYTJPY91Idqpkn+vJR+znqa6Ysye05pi IQGkc6cYnroFQ9IdXnI767xVQO55RQUo0YVfxf1nbgfmuJ1tbVC/PcWAB5CbSrnX6KwN palX/A+EitrYtHt+dM/SwcK3egfeV557lN+kT5K0cXS+SVr4a0ZVI2/KjULrwf2mUZ8u zfvg== X-Gm-Message-State: AOJu0Yw2xAD4UQT7yHT50b3AtXZqWoemvYkR63jQFhMG7MtNPL25epq7 WdsDSyX5kQgjBGvcFPI6aTnq1A== X-Google-Smtp-Source: AGHT+IGPSQl189u4mj/DlAOykR+AYywxq3ECsws9IbqA36ZO2Nq8EHZRjRwzqTROnnGJfm5Rgon2gw== X-Received: by 2002:a17:903:11c8:b0:1c7:23c9:a7e1 with SMTP id q8-20020a17090311c800b001c723c9a7e1mr9697515plh.26.1696608189693; Fri, 06 Oct 2023 09:03:09 -0700 (PDT) Received: from hermes.local (204-195-126-68.wavecable.com. [204.195.126.68]) by smtp.gmail.com with ESMTPSA id ji9-20020a170903324900b001c5900c9e8fsm4068970plb.81.2023.10.06.09.03.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Oct 2023 09:03:09 -0700 (PDT) Date: Fri, 6 Oct 2023 09:03:06 -0700 From: Stephen Hemminger To: Morten =?UTF-8?B?QnLDuHJ1cA==?= Cc: "Harman Kalra" , "Anatoly Burakov" , "David Hunt" , Subject: Re: How to rte_epoll_wait for IPC? Message-ID: <20231006090306.0ba9d5e6@hermes.local> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9EF02@smartserver.smartshare.dk> References: <98CBD80474FA8B44BF855DF32C47DC35E9EF02@smartserver.smartshare.dk> 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 Fri, 6 Oct 2023 12:03:46 +0200 Morten Br=C3=B8rup wrote: > 2. The "processing" thread receives its packets from the rte_ring. This t= hread should sleep until packets are ready for it in the rte_ring. >=20 > The "ingress" thread knows when it puts packets into the rte_ring, so it = can signal that event to the "processing" thread, to wake it up; either as = an interrupt/signal, or through a file descriptor. Is this supported by rte= _epoll (or other DPDK APIs), and how? When having to do this in applications, I used a eventfd() as well as the r= te ring. The ingress write's to eventfd and the other thread used epoll on the fd. Optimized this by having the ingress thread only signal via write if ring w= as in empty state. And the reader thread only needs to do (epoll/read) if ring became empty du= ring last cycle; i.e num packets from rte_ring_burst() was 0. Basically, when using epoll and other SW event models, you need to turn all= data sources into file descriptors.=20