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 6DC81A0093; Thu, 10 Mar 2022 17:16:15 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EFDA14113F; Thu, 10 Mar 2022 17:16:14 +0100 (CET) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by mails.dpdk.org (Postfix) with ESMTP id CEBA64113E; Thu, 10 Mar 2022 17:16:12 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 11120320187F; Thu, 10 Mar 2022 11:16:10 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 10 Mar 2022 11:16:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; bh=XyDU8vp6kyq2ZE ww0+dSXP7h3s0Qrv08UcPVpY00BWY=; b=QwtmxQs/mbvXLVJ4RwQ20nLr9sZeFM FMGGdK4yBI6Ur45/MO9a/h+QeDnVIgJBIdRt05TJI9cG47eRRXepKOJOznkSu4ft I49ujniyr6LalmD9zwLNqo3MSWC+CPIO/c5llGCW+6lVCUgfYd3V/od+8CqGYGU0 zjRiMz+xx81odmx7vjIplS9RKvXVpyNZw7nN18w6xfL1SK2qDequ27p9EoULLXSf 978wQWNb05qmz72achzad/z9zh/cUcsU74K5QxXj9dZrMYr7lGsnk5IX/tgrubpy Tt7l3/j5LKGkUveV4EHf0soIlFfuZZdTPabUN2xmhc48G9H+RF6z5EcA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=XyDU8vp6kyq2ZEww0+dSXP7h3s0Qrv08UcPVpY00B WY=; b=nmgnxwlokqkDGfHihmmgwSGL0rX7mVgNm+R9427hn1BB1oRVxvsMKUAJs 7/XeqALGg8PNYY+sJEs7+xbchDpuWo49vdwfKupP4d+F7fpk8/toqbqLZi8l7bx3 rsHG2iiM56Iw8kfH2PlYAyg08jBlHP/NEHvNMEfcVEDrITIW/EVZs4PMOzaaLR9f nItcR86B/Jup3LOA7s4WJwpKq8uUR/BIigdwrb4mC2J2jOClgLcQQr14szN+9MNE Fadgt+Eb70BIvOcmOo6liO8gqNDru54mJwXaUf8Zy07s4msp6b7puiXTrRk+dDhG tfB/I8Ek0JFG9Au3LRrhBZ+RZZeCw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddruddvtddgkeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepjeegtdffgfdugfduueeujedtgfefffegudehgedvfeegvddtjeev tdehhfekhffhnecuffhomhgrihhnpehoiihlrggsshdrohhrghenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 10 Mar 2022 11:16:09 -0500 (EST) From: Thomas Monjalon To: David Marchand Cc: Michael Baum , dev@dpdk.org, Matan Azrad , Raslan Darawsheh , Viacheslav Ovsiienko , dpdk stable Subject: Re: [PATCH] net/mlx5: fix FD configuration for Rx interrupt Date: Thu, 10 Mar 2022 17:16:06 +0100 Message-ID: <4694126.GXAFRqVoOG@thomas> In-Reply-To: References: <20220310131923.1144368-1-michaelba@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 10/03/2022 16:12, David Marchand: > On Thu, Mar 10, 2022 at 2:19 PM Michael Baum wrote: > > > > The mlx5_rx_intr_vec_enable() function allocates queue vector and fill > > FD list for Rx interrupts. > > > > The driver wrongly configured the FD with a non-blocking flag which > > prevent waiting on this FD. > > > > This patch removes O_NONBLOCK flag adding. > > - Maybe I deserve a Reported-by: credit on this issue. > I sent a proposal to make use of Rx interrupts in OVS > https://patchwork.ozlabs.org/project/openvswitch/patch/20220304161132.22065-1-david.marchand@redhat.com/. > And that's when I noticed that mlx5 rx fds were waking OVS too often > and reported it to mlx5 maintainers. > > > - Testing this patch by starting dpdk-l3fwd-power example (and no > traffic sent at all): > > # strace -r -f ./dpdk-dir/v21.11/examples/dpdk-l3fwd-power --lcores > 0@3,1@5 -a 0000:82:00.0 --in-memory -- -p 0x1 -P --config '(0,0,1)' > ... > [pid 534983] 0.000348 epoll_wait(26, [], 1, 10) = 0 > [pid 534983] 0.010082 read(24, > > For some reason, there is an event available for fd 18 right away > (which is the issue in the first place). > When reading this fd, read() blocks until an actual packet is received. > > Then, I send exactly one packet: > [pid 534983] 0.010082 read(24, "@\217:\370\21\0\0\0", 136) = 8 > [pid 534983] 9.228478 epoll_wait(26, [], 1, 10) = 0 > [pid 534983] 0.010082 read(24, > > That makes mlx5 rx interrupts unusable for an application that does > more than just polling one rxq. Excuse me, I don't understand this trace. What is the first read? Having a second read after epoll_wait is normal if a packet is received, isn't it?