From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE3B0C433B4 for ; Tue, 11 May 2021 17:22:20 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 2D4FD61221 for ; Tue, 11 May 2021 17:22:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2D4FD61221 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0E5A840140; Tue, 11 May 2021 19:22:19 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id 8E8324003E; Tue, 11 May 2021 19:22:17 +0200 (CEST) IronPort-SDR: 1XhPvGJA0wL/fqUcD98UWMVJMi0alIlnwKu/o5qhtvmjsYFTXePiu+XbGS+DT3zojy+2kkoA3o SBlQG3Fl1prA== X-IronPort-AV: E=McAfee;i="6200,9189,9981"; a="263433394" X-IronPort-AV: E=Sophos;i="5.82,291,1613462400"; d="scan'208";a="263433394" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 May 2021 10:22:13 -0700 IronPort-SDR: +JB2UfEFyUmZuAQJujGtEj4a5zeTOYs6yb9wRsrpfqZ54JbRRd/vPmhelDFQeYL+pGukq5A3Ba ekkhMvya1AEA== X-IronPort-AV: E=Sophos;i="5.82,291,1613462400"; d="scan'208";a="436765653" Received: from rmenon-desk.amr.corp.intel.com (HELO [10.166.30.253]) ([10.166.30.253]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 May 2021 10:22:13 -0700 To: Dmitry Kozlyuk , Thomas Monjalon Cc: dev@dpdk.org, stable@dpdk.org, Narcisa Ana Maria Vasile , Dmitry Malloy , Pallavi Kadam , Harman Kalra , Harini Ramakrishnan References: <20210502023333.30351-1-dmitry.kozliuk@gmail.com> <20210502023333.30351-3-dmitry.kozliuk@gmail.com> <2970635.tDqZXrgMp7@thomas> <20210511105934.104bbca5@sovereign> From: Ranjit Menon Message-ID: <331c7872-1513-1927-486c-27285a54144d@intel.com> Date: Tue, 11 May 2021 10:21:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <20210511105934.104bbca5@sovereign> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH 3/3] eal/windows: cleanup interrupt resources 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 Sender: "dev" On 5/11/2021 12:59 AM, Dmitry Kozlyuk wrote: > 2021-05-11 09:41 (UTC+0200), Thomas Monjalon: >> 02/05/2021 04:33, Dmitry Kozlyuk: >>> Interrupt manager in Windows EAL allocates on IOCP and starts >>> a control thread that runs indefinitely. At DPDK cleanup >>> this thread was not stopped and IOCP handle was not closed. >>> >>> Gracefully stop interrupt-handling in rte_eal_cleanup(). >>> The thread already closes IOCP handle before exiting. >>> >>> Fixes: 5c016fc0205a ("eal/windows: add interrupt thread skeleton") >>> Cc: stable@dpdk.org >>> >>> Signed-off-by: Dmitry Kozlyuk >>> --- >>> lib/eal/windows/eal.c | 1 + >>> lib/eal/windows/eal_interrupts.c | 26 ++++++++++++++++++++++++-- >>> lib/eal/windows/eal_windows.h | 5 +++++ >>> 3 files changed, 30 insertions(+), 2 deletions(-) >> It seems nobody reviewed. >> To be on the safe side, I'll merge this series after DPDK 21.05 is released. >> Or am I missing any critical issue? > IIRC Windows DPDK is not shipped anywhere yet, so the fix can be postponed. > > Without fix in 2/3 rte_eal_alarm_set() will start failing after some > thousands of calls (i40e calls every 50 ms, mlx5 call every 1 sec or less). > For mlx5 it seems to break flow counters (mlx5_flow_query_alarm function). It appears that Tyler reviewed and ack-ed this. I'll add my ACK too. If we can get this in to 21.05, it would be great. ranjit m.