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

["Betts, Ian" <ian.betts@intel.com>]

-----Original Message-----
From: Stephen Hemminger [mailto:stephen@networkplumber.org] 
Sent: Friday, December 4, 2015 6:04 PM
To: Betts, Ian
Cc: dev@dpdk.org; Richardson, Bruce
Subject: Re: [PATCH v8 0/4] examples: add performance-thread

>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...

These questions are valid and are the reason for making this an example application rather than a component library of DPDK. 
Making it an example gives people an opportunity to evaluate the concept, if it turns out to be of value it can be taken
forward, and if it turns out not to be of much interest we  will not evolve it.

There is a very detailed discussion in the accompanying sample app guide, which I believe provides enough information for most 
interested users to comprehend the scope of what is included, both in terms of the features, the limitations and porting guidance.

With respect to lthreads making system calls ( which is covered at some length in the documentation BTW), 
well this is the really the same questions as "what if a DPDK EAL thread made a system call ?"  
i.e. lthreads introduces no danger that does not already exist in a DPDK application.

Several existing fibre libraries were evaluated before starting down this road. 
This work itself is heavily influenced by one of those projects : https://github.com/halayli/lthread. 

There are a number of negatives with the existing implementations: None of those we looked at are
multicore capable, or at best only allow isolated instances of schedulers to be run on different cores. 
The more sophisticated examples provide their own socket APIs  with network IO via the kernel stack, which is not interesting for DPDK.
Nearly all of them use heavier context switch based on mkcontext and friends.

So far as insufficient time to consider then, this has been in the roadmap for 2.2 all along, and has been available
In patchwork for anybody to look at. There has been no adverse comment so far.