[PATCH v5] enhance NUMA affinity heuristic

[You, KaisenX]

> -----Original Message-----
> From: Thomas Monjalon <thomas at monjalon.net>
> Sent: 2023年4月21日 16:13
> To: You, KaisenX <kaisenx.you at intel.com>
> Cc: dev at dpdk.org; Zhou, YidingX <yidingx.zhou at intel.com>;
> david.marchand at redhat.com; Matz, Olivier <olivier.matz at 6wind.com>;
> ferruh.yigit at amd.com; zhoumin at loongson.cn; stable at dpdk.org;
> Richardson, Bruce <bruce.richardson at intel.com>; jerinj at marvell.com;
> Burakov, Anatoly <anatoly.burakov at intel.com>
> Subject: Re: [PATCH v5] enhance NUMA affinity heuristic
> 
> 21/04/2023 04:34, You, KaisenX:
> > From: Thomas Monjalon <thomas at monjalon.net>
> > > 13/04/2023 02:56, You, KaisenX:
> > > > From: You, KaisenX
> > > > > From: Thomas Monjalon <thomas at monjalon.net>
> > > > > >
> > > > > > I'm not comfortable with this patch.
> > > > > >
> > > > > > First, there is no comment in the code which helps to
> > > > > > understand the
> > > logic.
> > > > > > Second, I'm afraid changing the value of the per-core variable
> > > > > > _socket_id may have an impact on some applications.
> > > > > >
> > > > Hi Thomas, I'm sorry to bother you again, but we can't think of a
> > > > better solution for now, would you please give me some suggestion,
> > > > and
> > > then I will modify it accordingly.
> > >
> > > You need to better explain the logic both in the commit message and
> > > in code comments.
> > > When it will be done, it will be easier to have a discussion with
> > > other maintainers and community experts.
> > > Thank you
> > >
> > Thank you for your reply, I'll explain my patch in more detail next.
> >
> > When a DPDK application is started on only one numa node,
> 
> What do you mean by started on only one node?
When the dpdk application is started with the startup parameter "-l 40-59" 
(this range is on the same node as the system cpu processor).Only memory is 
allocated for this node when the process is initialized.
> 
> > memory is allocated for only one socket.
> > When interrupt threads use memory, memory may not be found on the
> > socket where the interrupt thread is currently located,
> 
> Why interrupt thread is on a different socket?
The above only allocates memory on node1, but the interrupt thread is created on node0.
Interrupt threads are created by rte_ctrl_thread_create() ,rte_ctrl_thread_create()' 
does NOT run on main lcore, it can run on any core except data plane cores. 
So interrupt thread can run on any core.
> > and memory has to be reallocated on the hugepage, this operation can
> > lead to performance degradation.
> >
> > So my modification is in the function malloc_get_numa_socket to make
> > sure that the first socket with memory can be returned.
> >
> > If you can accept my explanation and modification, I will send the V6
> > version to improve the commit message and code comments.
> >
> > > > > Thank you for your reply.
> > > > > First, about comments, I can submit a new patch to add comments
> > > > > to help understand.
> > > > > Second, if you do not change the value of the per-core variable_
> > > > > socket_ id, /lib/eal/common/malloc_heap.c
> > > > > malloc_get_numa_socket(void)
> > > > > {
> > > > >         const struct internal_config *conf =
> eal_get_internal_configuration();
> > > > >         unsigned int socket_id = rte_socket_id();   // The return value of
> > > > > "rte_socket_id()" is 1
> > > > >         unsigned int idx;
> > > > >
> > > > >         if (socket_id != (unsigned int)SOCKET_ID_ANY)
> > > > >                 return socket_id;    //so return here
> > > > >
> > > > > This will cause return here, This function returns the socket_id
> > > > > of unallocated memory.
> > > > >
> > > > > If you have a better solution, I can modify it.
> 
> 
>