From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; Fri, 10 Nov 2017 11:13:31 +0100 (CET) Received: by mail-wm0-f67.google.com with SMTP id r68so5285771wmr.0 for ; Fri, 10 Nov 2017 02:13:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=z0Jg9yrF5Nw85oKGvpkwJbEHzVHe9BOBovYaYLjbHHQ=; b=nGa8cpgK19hZdfmdrlIynRl/XbZMzgTzMB/J+EBhNSDxAPb5xMElJNZJJFZLBzRDj1 qPz32M+ASAka+WzP3lIMOeIJZMOhUwYU0vcwnAMBC6h0v9v6teDQGrqyx4Ut1iJ1G8ys Co5Dym4ek+rQwtp/vdcPpgVANAZvk3w18OSTHDm6BUu6Evmbuo12M/8GpZmwwv34fht+ z/FqZV5rRw4lJ/oQC0AjFQPeoRBFZ7VJyuzjOdNfeKj4orP4BzJluHXqYxyYK9yjbdZR rwRUWdK8OxD/B4BBjbpuhKxz4VUUOl4EzJpV5/1D5bUXLIfy+H5ZqHQ2ZfRrXouvYu/9 T2nw== X-Gm-Message-State: AJaThX647qgZWC7Ylc46OqbwZHIbXpIiUZF7ufuDjEhWLn9u/JPRyjkV 9SaWqWSEGKCSybazsVA4jHGjRg== X-Google-Smtp-Source: ABhQp+QhlOXehtYiGpSHo8gmgg+z/tcmLd82P7ztdY+De165OCnua7kwCiGz7VIL/aL5TlLIJ2l81w== X-Received: by 10.80.133.203 with SMTP id q11mr1825040edh.50.1510308811681; Fri, 10 Nov 2017 02:13:31 -0800 (PST) Received: from t460s.bristot.redhat.com ([193.205.81.200]) by smtp.gmail.com with ESMTPSA id e14sm7604787edk.95.2017.11.10.02.13.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 02:13:30 -0800 (PST) To: Adrien Mazarguil , Marcelo Tosatti Cc: dev@dpdk.org, Luiz Capitulino References: <20171110060210.GA23340@amt.cnet> <20171110091219.GE24849@6wind.com> From: Daniel Bristot de Oliveira Message-ID: Date: Fri, 10 Nov 2017 11:13:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171110091219.GE24849@6wind.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] testpmd: add nanosleep in main loop 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: , X-List-Received-Date: Fri, 10 Nov 2017 10:13:32 -0000 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