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 83D8DA034F; Wed, 10 Nov 2021 10:21:16 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 33F5C4068B; Wed, 10 Nov 2021 10:21:16 +0100 (CET) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by mails.dpdk.org (Postfix) with ESMTP id 8143B40683 for ; Wed, 10 Nov 2021 10:21:14 +0100 (CET) X-IronPort-AV: E=McAfee;i="6200,9189,10163"; a="213364989" X-IronPort-AV: E=Sophos;i="5.87,223,1631602800"; d="scan'208";a="213364989" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Nov 2021 01:21:13 -0800 X-IronPort-AV: E=Sophos;i="5.87,223,1631602800"; d="scan'208";a="452235283" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.18.229]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 10 Nov 2021 01:21:10 -0800 Date: Wed, 10 Nov 2021 09:21:07 +0000 From: Bruce Richardson To: Stephen Hemminger Cc: Tyler Retzlaff , Narcisa Ana Maria Vasile , thomas , "dev@dpdk.org" , Dmitry Kozlyuk , Khoa To , Dmitry Malloy , talshn , Omar Cardona , "david.marchand@redhat.com" , "Kadam, Pallavi" Message-ID: References: <1633732841-17873-1-git-send-email-navasile@linux.microsoft.com> <11591275.oo6G3FHbOz@thomas> <20211109015923.GB12569@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <6965604.4qUlQkvJ3b@thomas> <20211110030417.GA7558@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20211109195931.2c26f51e@hermes.local> <20211109222925.262dfec1@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211109222925.262dfec1@hermes.local> Subject: Re: [dpdk-dev] [EXTERNAL] Re: [PATCH v16 2/9] eal: add thread attributes 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 Tue, Nov 09, 2021 at 10:29:25PM -0800, Stephen Hemminger wrote: > On Wed, 10 Nov 2021 04:20:52 +0000 > Tyler Retzlaff wrote: > > > > > > > > > High performance applications benefit from an option to raise the > > > > priority of their threads to avoid being preemted by other threads on > > > > the system. If there are issues with realtime priority on some of the > > > > platforms, maybe we can add a warning for the user to make them aware > > > > of possible crashes as Stephen H. suggested some time ago. Note that > > > > this patch doesn't change the priority of EAL threads, enabling the higher priority will be done through a command line option when starting the application. > > > > Maybe we can explore raising the priority but not to the realtime level. > > > > > Let me put it more succulently. > > > Almost all DPDK applications have threads that are a 100% CPU doing polling. > > > Putting those thread as real-time thread breaks Linux badly because the kernel can and will try and run work on those CPU's and the system is broken/unstable/dead at that point. > > > > The suggestion is that when running on Windows it should be possible for the application to be configured to use real-time threads, there is no implication that it will force real-time priority on Linux. If it doesn't make sense for it to be configured on Linux then don't configure it. But saying it shall not be configurable for any platform just because one platform can't make use of the configuration and those platforms have to run compromised makes little sense. Linux administrators are (or should be) knowledgeable enough to know what configuration to use. > > > > Why not just make it always return an error when real-time is requested on Linux from a DPDK thread. > I would tend to agree with this suggestion, that we just return ENOTSUP error code for Linux. It's too easy to lock up a linux system with realtime DPDK threads. If a user really knows what they are doing and they need realtime priority on linux, they can use the linux scheduler APIs directly. However, I am ok with having such a function supported on Windows if it's needed. Unfortunately, I don't know for sure about BSD, but it probably should follow the linux approach initially unless proved safe. /Bruce