[dpdk-dev] [PATCH v8 00/19] support multi-pthread per core

Liang, Cunming cunming.liang at intel.com
Wed Feb 25 02:25:09 CET 2015



> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, February 25, 2015 2:53 AM
> To: Liang, Cunming
> Cc: Ananyev, Konstantin; dev at dpdk.org; olivier.matz at 6wind.com;
> nhorman at tuxdriver.com
> Subject: Re: [PATCH v8 00/19] support multi-pthread per core
> 
> > > v8 changes:
> > >   keep using strlen for trusted input string
> > >
> > > v7 changes:
> > >   update EAL version map for new public EAL API
> > >   rollback to use strnlen() passing EAL core option
> > >
> > > v6 changes:
> > >   rename RTE_RING_PAUSE_REP(_COUNT) and set default to 0
> > >   rollback to use RTE_MAX_LCORE when checking valid lcore_id for EAL thread
> > >
> > > v5 changes:
> > >   reorder some patch and split into addtional two patches
> > >   rte_thread_get_affinity() return type change to avoid
> > >   add RTE_RING_PAUSE_REP into config and by default turn off
> > >
> > > v4 changes:
> > >   new patch fixing strnlen() invalid return in 32bit icc [03/17]
> > >   update and add more comments on sched_yield() [16/17]
> > >
> > > v3 changes:
> > >   new patch adding sched_yield() in rte_ring to avoid long spin [16/17]
> > >
> > > v2 changes:
> > >   add '<number>-<number>' support for EAL option '--lcores' [02/17]
> > >
> > > The patch series contain the enhancements of EAL and fixes for libraries
> > > to run multi-pthreads(either EAL or non-EAL thread) per physical core.
> > > Two major changes list as below:
> > > - Extend the core affinity of each EAL thread to 1:n.
> > >   Each lcore stands for a EAL thread rather than a logical core.
> > >   The change adds new EAL option to allow static lcore to cpuset assginment.
> > >   Then a lcore(EAL thread) affinity to a cpuset, original 1:1 mapping is the
> special case.
> > > - Fix the libraries to allow running on any non-EAL thread.
> > >   It fix the gaps running libraries in non-EAL thread(dynamic created by user).
> > >   Each fix libraries take care the case of rte_lcore_id() >= RTE_MAX_LCORE.
> > >
> > > Thanks a million for the comments from Konstantin, Bruce, Mirek and
> Stephen in RFC review.
> > >
> > > Cunming Liang (19):
> > >   eal: add cpuset into per EAL thread lcore_config
> > >   eal: fix PAGE_SIZE redefine complaint on freebsd
> > >   eal: new eal option '--lcores' for cpu assignment
> > >   eal: fix wrong strnlen() return value in 32bit icc
> > >   eal: add public function parsing socket_id from cpu_id
> > >   eal: new TLS definition and API declaration
> > >   eal: add eal_common_thread.c for common thread API
> > >   eal: standardize init sequence between linux and bsd
> > >   eal: add rte_gettid() to acquire unique system tid
> > >   eal: apply affinity of EAL thread by assigned cpuset
> > >   enic: fix re-define freebsd compile complain
> > >   malloc: fix the issue of SOCKET_ID_ANY
> > >   log: fix the gap to support non-EAL thread
> > >   eal: set _lcore_id and _socket_id to (-1) by default
> > >   eal: fix recursive spinlock in non-EAL thraed
> > >   mempool: add support to non-EAL thread
> > >   ring: add support to non-EAL thread
> > >   ring: add sched_yield to avoid spin forever
> > >   timer: add support to non-EAL thread
> >
> > Acked-by: Konstantin Ananyev <konstantin.ananyev at intel.com>
> 
> I tried to fix many english typos. Please consider it during reviews.
> Cunming, you'll repeat 10 times "non-EAL threads compute more than none" ;)
> 
> Applied, thanks
[Liang, Cunming] Thanks, Thomas. I'll take care of it next time. :)
> 
> My main concern in this patchset is about naming. Now lcore means thread
> in many places. I would prefer to have a cleanup to use right term at
> right place, even if it requires breaking API.
[Liang, Cunming] 'lcore' is limited used as EAL thread.
Comparing to the legacy usage, the difference is such lcore(logical core) may not only affinity to one physical core.
If extending the meaning of 'lcore' a bit wider (as prog_guide doc said, let's consider a logical core stands for an EAL thread), it then makes sense to keep origin APIs.
That helps the existing apps migrate transparently.
> 
> Are we going to deprecate the fresh option -l in favor of --lcores/--threads?
[Liang, Cunming] I think so, as '--lcores' already covered '-l' pattern.
Mark it as deprecated, and remove it on next version ?



More information about the dev mailing list