> -----Original Message----- > From: Burakov, Anatoly <anatoly.bura...@intel.com> > Sent: Tuesday, February 16, 2021 10:53 AM > To: Richardson, Bruce <bruce.richard...@intel.com>; Van Haaren, Harry > <harry.van.haa...@intel.com> > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] eal: support using 0 as coremask for no- > affinitization > > On 16-Feb-21 10:46 AM, Bruce Richardson wrote: > > On Tue, Feb 16, 2021 at 10:36:13AM +0000, Burakov, Anatoly wrote: > >> On 16-Feb-21 9:43 AM, Bruce Richardson wrote: > >>> Allow the user to specify that they don't want any core pinning from DPDK > >>> by passing in the coremask of 0. > >>> --- > >> > >> I haven't checked what happens yet, but down the line we also set affinity > >> for service cores as well as interrupt thread. what would be the semantics > >> of those in this particular case? do we want the same ability for service > >> cores (i.e. pick a non-affinitized core)? And where does interrupt thread > >> affinitize in this case (presumably, nowhere too)? > >> > > I have not checked the service core setup, because a) I forgot about them > > and b) I'm not sure how their affinity rules work with respect to the main > > lcore mask. On the other hand I did check out that the lcore mask for all > > non-pinned threads, or control threads, is the full set of bits as > > expected. > > > > /Bruce > > > > +Harry, > > I believe service core mask must not overlap with lcore masks, so > presumably using 0 as lcore mask would make it so that any service core > mask will be valid (which is presumably what we want?).
Services cores -S list or -s <mask> *must* overlap with the RTE lcores, EAL then"steals" the service cores from the application lcores, code that implements here: http://git.dpdk.org/dpdk-stable/tree/lib/librte_eal/common/eal_common_options.c?h=20.11#n657 > Should service cores also have a "just pick a core" parameter? I'm not sure, depends on what the bigger goal is here. Assuming we're enabling this for ROLE_RTE threads, then it would seem to me that ROLE_SERVICE and control threads would require similar treatment? > I'm assuming this use-case is explicitly avoiding the CPU/memory/NIA > NUMA affinity question, so i'm not bringing it up :) > > -- > Thanks, > Anatoly
