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 ADF054621D for ; Thu, 13 Feb 2025 23:26:19 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3354E402B9; Thu, 13 Feb 2025 23:26:19 +0100 (CET) Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) by mails.dpdk.org (Postfix) with ESMTP id D868C4003C for ; Thu, 13 Feb 2025 23:26:16 +0100 (CET) Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-220c8f38febso24970185ad.2 for ; Thu, 13 Feb 2025 14:26:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1739485576; x=1740090376; 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=C/Va8GPnBwHL3ozViCnddrPl+r7y/8rm7XUFHpaVX2Y=; b=Nq04v0jcQAzcWsW5EV34PfOIXFGuIZ9gotIz3SLNhHH//otQCe3FBctXAIdMzPP5/H zdnRS8QpfRT3ietj3h/ics/v0SwwNffScQCA3PZ9TZ+y05W5G37plXt8KFX2eybtmvQ6 Dzeu6ZIXhViDclHBbE0sZAYZCXkpQpyQ7MA1kjVyZ+IOe4U48QuLe8nlrfHpxwcwVk5a m3xXiuwdGo888FVTMaKSqFj3J1oV4VurLYXjapfChf2/j3M2AQ3ph/MN9Q0kwI/wIXNE J0oedHjFLvOy0zIMkkW6pHlbW/2/d8HCu0qTZwrAEd8yIqZOEe9jEb3NUsipissdPm3t hImQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739485576; x=1740090376; 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=C/Va8GPnBwHL3ozViCnddrPl+r7y/8rm7XUFHpaVX2Y=; b=ijhqcEvpF4uFspD1vuhuF65SbmeBZXiHMRqlQ9kyXfdIvv5xGk0Dl7n2AEzH82CNN6 s0Wt9uw1clmUjtUf6pINwESYbSI0LQ7dT8Ap/rR8xvkqGjUaAGSMRreBdWufcWWm/h7F y6Mm0VDVoq79hz5sDbsH3XAm9mSDEqdtMdmRQ9dm1CNhNgepE6rvj2WZDfzIHznkz0oQ d3DPY7+Ncao5/xU03FospzDeMG690QBxQNIpVTTVVkJtNun/wSkBraTlPWWWST7DsWwI X+qpmwpXCirTcTGQ3Y4rKB7RtbB1J5mqiHgWlTuwVEwZEzAi34dphKN1yH+/jySnkz2u e0bQ== X-Gm-Message-State: AOJu0YxWX+JWIRTypVjBEatEpJj0ptXcLjp8JUFj98qK0uDkANiT/MlG auKul7FYfNtCGgqdNl0S5de9BH/zSDp2Tv31osfLy0HgnjfNK+wkWQ5M7miFLFY= X-Gm-Gg: ASbGncsQL+5AUt0Y4LOtggV+6lHDC5OOSppjmu2O8db8a74U6PsbOAW25rGWpvK8CMI Llu5QKXdyjxFpiSWqXtpk8c4xBu1GafYpV5/rA9b3yNNNEsDRBbCKKQHIWxjZw9aGSbOsgtyB65 o3wqUIXAkMDvP7bqugaJ47QFjjkT5mxamCCDwBhmthSIRBuF1BxYWjCFteFoKnTzGwGm7T8gHRK r/536vcf49QJiHV58J67pHB51aN9sOtxsmzq1Eh5R+Gk/Fl0ssbXhHb3bvKDoQ9t/JAwc/ceXr6 aQ1qndZ7UoaY1hY16EFjqVedpaVImT0/9aLSyu1SSnwn8m5YgfD6qxoDO1jvYj/e99++ X-Google-Smtp-Source: AGHT+IG6XM2zcSrCQlA7bBm4/FqSo+x/jE1tqOn5Eyx0QhSVEO0M5q0NFuy24wW19BoQwzzUbxYTMA== X-Received: by 2002:a17:902:ce90:b0:212:63c0:d9e7 with SMTP id d9443c01a7336-220bdd15c1fmr153281375ad.0.1739485575912; Thu, 13 Feb 2025 14:26:15 -0800 (PST) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-220d556f967sm17309825ad.162.2025.02.13.14.26.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Feb 2025 14:26:15 -0800 (PST) Date: Thu, 13 Feb 2025 14:26:13 -0800 From: Stephen Hemminger To: Alan Beadle Cc: users@dpdk.org Subject: Re: Questions about interrupts Message-ID: <20250213142613.23d52f6b@hermes.local> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org On Thu, 13 Feb 2025 16:55:57 -0500 Alan Beadle wrote: > Hello, > > I am trying to use rte_epoll_wait() to avoid rx polling and reduce CPU > utilization while preserving low latency. I am using the Intel X550-T2 > NIC with DPDK 23.11 and the ixgbe driver. > > I was able to make interrupts work and my process is getting > interrupts when a packet arrives. I followed the example here: > https://stackoverflow.com/questions/69792978/using-interrupts-with-dpdk > > Before calling rte_epoll_wait(), I must first arm the interrupt by > calling rte_eth_dev_rx_intr_enable() every time my thread is about to > wait. However, if a packet arrives between these calls, the interrupt > will not work and my process will only resume once the timeout is > reached. This causes huge latency spikes unless my timeout is very > short, and the minimum time of 1ms is still too long to tolerate this > problem, since my goal is to keep latency low. After enabling interrupts, the application should do one more call to rx_burst which will see if there any packets that raced in. If it does get some packets, chances are you want to disable interrupts and go back to polling mode. See the l3fwd-power example application. > Here are my questions: > 1) Is there a way to prevent the thread from suspending at all if the > interrupt is not "armed" anymore? > 2) Is it possible to set a timeout shorter than 1 ms? It looks like > this is not supported by rte_epoll_wait(). Internally rte_epoll_wait is just a wrapper around the epoll system call. which takes a timeout in milliseconds. You could make a version of rte_epoll_wait using the newer epoll_pwait2 system call which accepts a timeout in nanosecond resolution. Read the source of EAL, it is much easier than trying to explain all this.