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 E7576431F0; Tue, 24 Oct 2023 18:04:55 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 797D7402C5; Tue, 24 Oct 2023 18:04:55 +0200 (CEST) Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com [209.85.215.169]) by mails.dpdk.org (Postfix) with ESMTP id 56D034021D for ; Tue, 24 Oct 2023 18:04:54 +0200 (CEST) Received: by mail-pg1-f169.google.com with SMTP id 41be03b00d2f7-565334377d0so3475440a12.2 for ; Tue, 24 Oct 2023 09:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1698163493; x=1698768293; 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=OTxa4CGGMbI9oWWazeXRYiXzQLD0T+3MPRqbD/5qDJE=; b=vQvUlu7LS1Wiyeezi5bvsqOA91LZElxIa57VeH6gebcmJiz2NuVgybeQf51sdULWpa 5PICYRJ5EGWKc+NxIrmFQj2NaJ/sm7iTGlfOgF4W55k6ZzSO8/6uhrZf3Oo1PsC/Q76y XRvLGyduTwfkvZZXqIul2T+qW5WGwqX0PGBN95e2fHJ7Mbo5gVgqulgSIlccw75YfNA0 7aheM+p1l44cZEMiUSp1sHgN75Mf2UitCpNZyWlkLVIdXBPSyoKslTN+fvTvLzQkEofA T2cCw0PNV1GsNgYTcNmN5+GotraI0d6/Epsten0Ehva9OZBgOil7P8Fsb5vtHY5e98sV AzRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698163493; x=1698768293; 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=OTxa4CGGMbI9oWWazeXRYiXzQLD0T+3MPRqbD/5qDJE=; b=UTuZ4/4+G+iTekVTpchM9eq2igkof9BGitZusAR8EohbP03k9xinRMY+cP/maGUBn3 NPiyHsFMnLDqJJUd8mFiyRNyjXqXWzeVBaEdHU/HUWlbbsn8G04XHxduIXuuRKWgQquT wteYdZ3vLv3IrGaMUjEyvecApqduTPZXZkI6m4nFQTflheDri/LQlJ0ugg5Q9PJB2sp4 2QKknB8+0YQ+c3ldSvro+M/QSqDrTgonHjvb9p076Jt+zHtKTBtzIFAwQK6vX1UikdwJ sKa9qdW5zsYJt7ihL4Fx1kdvKweCriCa8P8aqFCh4k6S9mXXnc1eMdGy1zJZzV8LRRZ9 X5xQ== X-Gm-Message-State: AOJu0YxrLv0/duhzmXVfQuCBHEFuFE+b84w8L8e0lRZUQRrZrLxQLiLG 3ZkrUWAq0b/LWO/n+pDBljPWhw== X-Google-Smtp-Source: AGHT+IHXN4yZTEK6NcK+NEDLQU9EXaCKEo1KVHsLxYpszGLpMSc9ypJIqRqoTccdOt7bJo+niJ/dCg== X-Received: by 2002:a17:90a:1a52:b0:27f:bd9e:5a10 with SMTP id 18-20020a17090a1a5200b0027fbd9e5a10mr4150682pjl.20.1698163492957; Tue, 24 Oct 2023 09:04:52 -0700 (PDT) Received: from hermes.local (204-195-126-68.wavecable.com. [204.195.126.68]) by smtp.gmail.com with ESMTPSA id 8-20020a17090a1a4800b002776288537fsm8048434pjl.53.2023.10.24.09.04.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Oct 2023 09:04:52 -0700 (PDT) Date: Tue, 24 Oct 2023 09:04:50 -0700 From: Stephen Hemminger To: Morten =?UTF-8?B?QnLDuHJ1cA==?= Cc: "Thomas Monjalon" , , "David Marchand" , , "Anatoly Burakov" , "Narcisa Vasile" , "Tyler Retzlaff" , "Dmitry Kozlyuk" , "Konstantin Ananyev" , "Andrew Rybchenko" Subject: Re: [PATCH] eal/unix: allow creating thread with real-time priority Message-ID: <20231024090450.519ac82b@hermes.local> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9EF75@smartserver.smartshare.dk> References: <20231024125416.798897-1-thomas@monjalon.net> <98CBD80474FA8B44BF855DF32C47DC35E9EF75@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 On Tue, 24 Oct 2023 15:55:13 +0200 Morten Br=C3=B8rup wrote: > >=20 > > 4. It MAY be used by preemptible multi-producer and/or preemptible m= ulti- > > consumer pthreads whose scheduling policy are all SCHED_OTHER(cfs), SCH= ED_IDLE > > or SCHED_BATCH. User SHOULD be aware of the performance penalty before = using > > it. > >=20 > > - 5. It MUST not be used by multi-producer/consumer pthreads, whose > > scheduling policies are SCHED_FIFO or SCHED_RR. > > + 5. It MUST not be used by multi-producer/consumer pthreads > > + whose scheduling policies are ``SCHED_FIFO`` > > + or ``SCHED_RR`` (``RTE_THREAD_PRIORITY_REALTIME_CRITICAL``). =20 >=20 > Do the RTS or HTS ring modes make any difference here? >=20 > Anyway, I agree that real-time priority should not be forbidden on Unix. >=20 > Acked-by: Morten Br=C3=B8rup Please add a big warning message in the rte_thread.c and the documentation to describe the problem. Need to have the "you have been warned" action. Use of RT priority is incompatible with 100% poll mode as is typically done in DPDK applications. A real time thread has higher priority than other nec= essary kernel threads on the same CPU. Therefore if the RT thread never sleeps, cr= itical system actions such as delayed writes, network packet processing and timer = updates will not happen which makes the system unstable. Multiple DPDK users have learned this the hard way.