Re: [dpdk-dev] [PATCH] eal: support using 0 as coremask for no-affinitization

["Van Haaren, Harry" <harry.van.haaren@intel.com>]

> -----Original Message-----
> From: Burakov, Anatoly <anatoly.burakov@intel.com>
> Sent: Tuesday, February 16, 2021 10:53 AM
> To: Richardson, Bruce <bruce.richardson@intel.com>; Van Haaren, Harry
> <harry.van.haaren@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