OK please send v6 with comments in the code where appropriate.
We'll continue the discussion in v6.
Thanks
23/04/2023 10:57, You, KaisenX:
>
> > -----Original Message-----
> > From: You, KaisenX <kaisenx....@intel.com>
> > Sent: 2023年4月23日 14:52
> > To: Thomas Monjalon <tho...@monjalon.net>
> > Cc: dev@dpdk.org; Zhou, YidingX <yidingx.z...@intel.com>;
> > david.march...@redhat.com; Matz, Olivier <olivier.m...@6wind.com>;
> > ferruh.yi...@amd.com; zhou...@loongson.cn; sta...@dpdk.org;
> > Richardson, Bruce <bruce.richard...@intel.com>; jer...@marvell.com;
> > Burakov, Anatoly <anatoly.bura...@intel.com>
> > Subject: RE: [PATCH v5] enhance NUMA affinity heuristic
> >
> >
> >
> > > -----Original Message-----
> > > From: Thomas Monjalon <tho...@monjalon.net>
> > > Sent: 2023年4月21日 16:13
> > > To: You, KaisenX <kaisenx....@intel.com>
> > > Cc: dev@dpdk.org; Zhou, YidingX <yidingx.z...@intel.com>;
> > > david.march...@redhat.com; Matz, Olivier <olivier.m...@6wind.com>;
> > > ferruh.yi...@amd.com; zhou...@loongson.cn; sta...@dpdk.org;
> > > Richardson, Bruce <bruce.richard...@intel.com>; jer...@marvell.com;
> > > Burakov, Anatoly <anatoly.bura...@intel.com>
> > > Subject: Re: [PATCH v5] enhance NUMA affinity heuristic
> > >
> > > 21/04/2023 04:34, You, KaisenX:
> > > > From: Thomas Monjalon <tho...@monjalon.net>
> > > > > 13/04/2023 02:56, You, KaisenX:
> > > > > > From: You, KaisenX
> > > > > > > From: Thomas Monjalon <tho...@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.
> To avoid ambiguity, I'll explain my commet again. Interrupt threads are
> created by
> rte_ctrl_thread_create() , rte_ctrl_thread_create() doesn't control which
> node the
> thread it creates runs on, interrupt threads 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.
> > >
> > >
> > >
>
>
