Re: [PATCH v2] eal/linux: fix fbarray name with multiple secondaryprocesses

On Fri, 15 Nov 2024, Stephen Hemminger wrote: > Need to include to get the prototype rte_get_tsc_cycles() For the code without could run on x86, I think I have found the reason. Through the path -> -> , the is included. is independent on each architecture. And on x86 the includes its

Re: [PATCH v2] eal/linux: fix fbarray name with multiple secondaryprocesses

On Fri, 15 Nov 2024, Stephen Hemminger wrote: > Need to include to get the prototype rte_get_tsc_cycles() When I compile locally (on x86), it compiles successfully whether or not is included. However, cloud testing indicates that compilation fails on other architectures when is not include

Re: [PATCH] eal/linux: redefine the name for rte_fbarray_init()

On Thu, 14 Nov 2024, Stephen Hemminger wrote: > Date: Fri, 15 Nov 2024 01:06:27 > From: Stephen Hemminger > To: zcjie0802 > Cc: dev , anatoly.burakov > Subject: Re: [PATCH] eal/linux: redefine the name for rte_fbarray_init() > > What about using thread id instead? > > From d1687ffbf865ba0b2d6

Re: [PATCH] eal/linux: redefine the name for rte_fbarray_init()

On Thu, 14 Nov 2024, Stephen Hemminger wrote: > > In general DPDK uses tsc instead of monotonic time, since it is faster and > platform > independent (ie Windows). > > Why not use use a global counter instead? > I have tried tsc, but it only works on x86 and does not function on other archi

Re: [PATCH] eal/linux: redefine the name for rte_fbarray_init()

On Thu, 14 Nov 2024, Stephen Hemminger wrote: > > In general DPDK uses tsc instead of monotonic time, since it is faster and > platform > independent (ie Windows). > > Why not use use a global counter instead? > I have tried tsc, but it only works on x86 and does not function on other archs.