From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5608DA04BB; Thu, 24 Sep 2020 23:38:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 779D41DEEF; Thu, 24 Sep 2020 23:38:38 +0200 (CEST) Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) by dpdk.org (Postfix) with ESMTP id 744131DECA for ; Thu, 24 Sep 2020 23:38:37 +0200 (CEST) Received: by mail-lj1-f194.google.com with SMTP id b19so649171lji.11 for ; Thu, 24 Sep 2020 14:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=2U4LTwYRMjE6ZFW0X6qJ4ObhJUa3jFi3CH2D9oiOUwc=; b=vCEgPZyGK5T5Li48STs/nlSjaluucQ0hTQNSMTER0Djhr75Y012sur2Wgfwr4tIrF0 x+uWT+Bp5ybaxHUXb1qMpO73MCErWHvLG95z9ySoX4seU5U636z42Y0Wsc06wxRxxG2J LxRlBKH7PxnASaiiz//5mROlgTNz8OicwDfWVRjlXfhSr+y09Pkyrw3zztSgG83FIa97 3adQIK614DSH0jzq9Qeb11rLNr8C2rQgFjGs+ZZLptqDtWQT6y0J1akXppWrXL2zy69w jUWwh7jlk0++ylFz+s/qcaGMWgYX1jfEmCHBLwLxVa2ubkG6OaQkuG/2xwS3dkZIypbQ Lvvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=2U4LTwYRMjE6ZFW0X6qJ4ObhJUa3jFi3CH2D9oiOUwc=; b=L/Mk5IgsuO6TNVBq0UzLCdtJqx7DlaP2OHmTsJz60UZix9sRNSb0eDwECGnZ7g6614 s3mljmagIAbJ6Vwst51B0wDJXJO06y8OGRERbG+EZxPskgXcPUXqncQkGprpS5/djPQs mSW3msONIaIo7DaZaTaXdCNOpjqwsalI2TtstIl5cb8gzNFr5vGHbPhCKxLK5F6ZsKZ9 vX39PBTuBEVtk0i157SWFBBBYIDjHyQ0cUdH7mdvXCscfov6n4vrLV7hUkgP1wxmOFzW /sKv4tPsWvDec7Fb/8wxYr9aW1fYLvEJrxC+Z9Fdl0y8wbSWzXeJD8RYM3Euoc6CTRN9 eBYQ== X-Gm-Message-State: AOAM530I374hLJWrMnsCyOzb5t98U5KpycBI3FRGVx35LJWkiR8cGsMY VUqNCeFuFNhthojcudN64uw= X-Google-Smtp-Source: ABdhPJwyAXUHlPuq1rgDCKHT8aGq9THk4XUQZC7JhxujuLFJsgbV3fA4pyQoyBnM2SqOtTfgyx0iBA== X-Received: by 2002:a2e:8ed2:: with SMTP id e18mr294920ljl.466.1600983517025; Thu, 24 Sep 2020 14:38:37 -0700 (PDT) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id x5sm426435lfd.119.2020.09.24.14.38.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Sep 2020 14:38:35 -0700 (PDT) Date: Fri, 25 Sep 2020 00:38:34 +0300 From: Dmitry Kozlyuk To: Khoa To Cc: "dev@dpdk.org" , Narcisa Ana Maria Vasile , "Dmitry Malloy (MESHCHANINOV)" , Pallavi Kadam Message-ID: <20200925003834.2266e7a2@sovereign> In-Reply-To: References: <20200911002207.31813-1-dmitry.kozliuk@gmail.com> <20200911002207.31813-3-dmitry.kozliuk@gmail.com> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [EXTERNAL] [PATCH 2/2] eal/windows: implement alarm API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" Hi Khoa, Disclaimer: my experience with interrupts and alarms is limited. > Since all alarm callbacks are scheduled on the interrupt thread, looks like this implementation of rte_eal_alarm_set() would create a head-of-line blocking issue, as the callbacks are serialized one after the other. > Is that correct? If so, while this does not violate the API contract, it seems undesirable. Yes, the issues is valid, however, probably irrelevant. In DPDK, alarms are considered on par with interrupts. Much like kernel ISRs, DPDK interrupt callbacks are supposed to be short. When they need to do more work, there are facilities to schedule deferred work (again, somewhat like NT kernel DPC): rte_ctrl_thread_create(). > I'm wondering why in both Linux and this Windows implementation, we don't spawn a new thread to service each alarm independently. These threads would need cores to be scheduled on. If we set affinity to the primary lcore, head-of-line issue is back. If we leave that to the OS, they may land on data-plane cores with a context switch. > And, regardless of the Linux implementation, should we consider another implementation that avoids the head-of-line blocking issue? I don't think so. Looking at PMD code, timers are mostly used during initialization or reconfiguration.