From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Bristot de Oliveira <bristot@redhat.com>
Subject: Re: [PATCH] testpmd: add nanosleep in main loop
Date: Fri, 10 Nov 2017 11:13:30 +0100
Message-ID: <fcd3bd23-3add-9cda-3ead-671126be0c91@redhat.com>
References: <20171110060210.GA23340@amt.cnet>
 <20171110091219.GE24849@6wind.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Cc: dev@dpdk.org, Luiz Capitulino <lcapitulino@redhat.com>
To: Adrien Mazarguil <adrien.mazarguil@6wind.com>,
 Marcelo Tosatti <mtosatti@redhat.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67])
 by dpdk.org (Postfix) with ESMTP id 12AD11B6BE
 for <dev@dpdk.org>; Fri, 10 Nov 2017 11:13:31 +0100 (CET)
Received: by mail-wm0-f67.google.com with SMTP id r68so5285771wmr.0
 for <dev@dpdk.org>; Fri, 10 Nov 2017 02:13:31 -0800 (PST)
In-Reply-To: <20171110091219.GE24849@6wind.com>
Content-Language: en-US
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On 11/10/2017 10:12 AM, Adrien Mazarguil wrote:
> Since testpmd is a development tool not supposed to run in a production
> environment, is there really a need for it to be patched to work around a
> (temporary) Linux kernel bug?

>>From the kernel side... not even...

> If so, why is I/O the only forwarding mode impacted?
> 
> If it's used in a production environment and such a fix can't wait, have
> other workarounds been considered:
> 
> - Replacing testpmd in I/O mode with a physical cable or switch?

using proper options like:

> - Using proper options on the kernel command line as described in [1], such
>   as isolcpus, rcu_nocbs, nohz_full?

Guarantees you that a CPU is completely isolated. In the current state
of the art, it is not possible to assume that a CPU can be fully
isolated from OS housekeeping threads.

For example, some kernel sub-systems rely on executing on every CPU,
e.g., using kworkers, and they are not only tracing or debugging
options. That case Marcelo showed is just a straightforward to use use-case.

If a busy-loop-isolated task runs with rt priority, it will end up
delaying such workers to run, making system to complain about hung tasks.

-- Daniel