From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 119511B185; Thu, 14 Feb 2019 11:05:02 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2019 02:05:01 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,368,1544515200"; d="scan'208";a="144199706" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.252.18.208]) ([10.252.18.208]) by fmsmga004.fm.intel.com with ESMTP; 14 Feb 2019 02:05:00 -0800 To: David Marchand Cc: dev@dpdk.org, Olivier Matz , Kevin Traynor , dpdk stable References: <1550074412-31285-1-git-send-email-david.marchand@redhat.com> From: "Burakov, Anatoly" Message-ID: <4304821e-dd76-da80-2dec-e1c540e95ea5@intel.com> Date: Thu, 14 Feb 2019 10:04:59 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] eal: restrict ctrl threads to startup cpu affinity 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: Thu, 14 Feb 2019 10:05:03 -0000 On 14-Feb-19 9:53 AM, David Marchand wrote: > On Thu, Feb 14, 2019 at 10:39 AM Burakov, Anatoly > > wrote: > > On 13-Feb-19 4:13 PM, David Marchand wrote: > > Spawning the ctrl threads on anything that is not part of the eal > > coremask is not that polite to the rest of the system. > > > > Rather than introduce yet another eal options for this, let's take > > the startup cpu affinity as a reference and remove the eal coremask > > from it. > > If no cpu is left, then we default to the master core. > > > > The cpuset is computed once at init before the original cpu affinity. > > > > Fixes: d651ee4919cd ("eal: set affinity for control threads") > > Signed-off-by: David Marchand > > > --- > > Hi David, > > Maybe i didn't have enough coffee today and i'm missing something here, > but how is this different? Removing the coremask cores from the cpuset > will effectively "spawn the ctrl threads on anything that is not > part of > the EAL coremask" (which is "not that polite to the rest of the > system"), unless the application was run with taskset. > > Is "taskset" the key point here? I.e. by default, we're still "not > polite", unless the user asks nicely? :) > > > Eheh, sorry, yes. > A bit more context then, if you want to clearly pin cpu resources for > the processes on your system (let's say having virtual machines and a > popular vswitch), I can only think of two solutions. > Either you have something to configure your processes to have them call > sched_setaffinity/pthread_set_affinity_np, or you use taskset to get > them "jailed" without them caring. > > Before the incriminated commit, we were keeping all threads on the > coremask that had been passed, but as Olivier said, we would end up with > ctrl threads spanwed on core running dataplane threads as well. > > Now, the ctrl threads can be spawned anywhere on all & ~coremask, with > no way to configure this. > I considered adding a new eal option, but I think relying on the current > cpu affinity is a better default behavior and I can't see drawbacks at > the moment. > > > -- > David Marchand > OK, that makes sense. However, i feel this behavior (both old and new, for that matter) should be better documented somewhere in the EAL docs. -- Thanks, Anatoly