Re: [dpdk-dev] [PATCH v8 0/4] examples: add performance-thread

[Stephen Hemminger <stephen@networkplumber.org>]

On Fri,  4 Dec 2015 10:34:21 +0000
Ian Betts <ian.betts@intel.com> wrote:

> This patchset comprises a layer 3 forwarding derivative intended to
> facilitate characterization of performance with different
> threading models, specifically:-
> 
> 1. EAL threads running on different physical cores
> 2. EAL threads running on the same physical core
> 3. Lightweight threads running in an EAL thread
> 
> Purpose and justification
> 
> Since dpdk 2.0 it has been possible to assign multiple EAL threads to
> a physical core ( case 2 above ).
> Currently no example application has focused on demonstrating the
> performance constraints of differing threading models.
> 
> Whilst purpose built applications that fully comprehend the DPDK
> single threaded programming model will always yield superior
> performance, the desire to preserve ROI in legacy code written for
> multithreaded operating environments  makes lightweight threads
> (case 3 above) worthy of consideration.
> 
> As well as aiding with legacy code reuse, it is anticipated that
> lightweight threads will make it possible to scale a multithreaded
> application with fine granularity allowing an application  to more
> easily take advantage of headroom on EAL cores, or conversely occupy
> more cores, as dictated by system load.
> 
> To explore performance with lightweight threads a simple cooperative
> scheduler subsystem is being included in this example application.
> If the expected benefits and use cases prove to be of value, it is
> anticipated that this lightweight thread subsystem would become a
> library in some future DPDK release.
> 
> Changes in this version
> * remove ASM implementation of atomic64_xchg in favor
>    of builtin __sync_lock_test_and_set()

Looks useful, but this needs more discussion.

Maybe it should be a separate library not tied into DPDK so
it gets wider use and testing? Also what are the limitations?
What if an lthread did a system call? What about interaction
with rte_poll?

Earlier attempts at lightweight threading (fibers) would be worth
looking into. http://c2.com/cgi/wiki?CooperativeThreading
Intel Thread Building Blocks
IBM NGPT (now defunct)

There lots of hidden gotcha's here, like preemption (or not),
and limitations on interactions with other libraries.

Intel may have some milestone to get it into DPDK 2.2 but
really this seems too late...