Hi Nick,

> -----Original Message-----
> From: dev <dev-boun...@dpdk.org> On Behalf Of Nick Connolly
> Sent: Monday, October 19, 2020 2:59 AM
> To: dev@dpdk.org
> Subject: [EXTERNAL] [dpdk-dev] [RFC] pthread on Windows
> 
> 
> The proposed changes are:
> 
>  1. An EAL implementation of pthread with a new rte_pthread API.
>  2. The DPDK code (libs, examples, drivers, apps, tests, etc) needs to
>     be modified to use the new rte_pthread API.
>  3. There needs to be an option for apps to use an external pthread
>     library as an alternative to the EAL implementation.
>  4. Eventually, apps can opt in to using the rte_pthread API if desired.
> 
> Item #3 isn't dependent on #1 and #2 - it can be implemented now,
> allowing forward progress to be made without blocking on #1 and #2 which
> may take longer to resolve.
> 
> 

One concern I have with starting on #3 first is that with this patch, we make 
pthread semantics mandatory for DPDK core. When new code which references 
pthread API is later added to DPDK core, and that functionality doesn’t yet 
have a Windows emulation in EAL, DPDK core may take the dependency on a certain 
pthread semantics that (a) not implemented before, and (b) is hard to emulate.

That could represent a problem later, when we introduce the “EAL threads” API 
layer with a more loose semantics (which can be backed by either external 
pthread library, or by emulation on Windows).

Given that a compile flag is not part of any patch submission that introduces 
such new pthread dependency, how do we detect this problem during said 
submission?

Do we know if there is a test or submit requirements which ensures that DPDK 
compiles on all platforms/environments (including this flag to use external 
pthread library) to catch new pthread dependencies, prior to accepting any new 
patch?

Khoa.

Reply via email to