From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Burakov, Anatoly" Subject: Re: [PATCH] eal: restrict ctrl threads to startup cpu affinity Date: Thu, 14 Feb 2019 10:04:59 +0000 Message-ID: <4304821e-dd76-da80-2dec-e1c540e95ea5@intel.com> References: <1550074412-31285-1-git-send-email-david.marchand@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, Olivier Matz , Kevin Traynor , dpdk stable To: David Marchand Return-path: In-Reply-To: Content-Language: en-US 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 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