+Dmitry, Harini Hi Nick,
> -----Original Message----- > From: Nick Connolly <nick.conno...@mayadata.io> > Sent: Monday, November 2, 2020 3:17 AM > To: Khoa To <k...@microsoft.com>; dev@dpdk.org > Subject: Re: [EXTERNAL] [dpdk-dev] [RFC] pthread on Windows > > Hi Khoa, > > On 29/10/2020 21:19, Khoa To wrote: > >> -----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. > > I think we are ok here ... the patch doesn't change any dependencies, or > make pthreads semantics mandatory for DPDK core. Any changes to DPDK > core will be built and tested against the Windows EAL in exactly the > same way as currently and the same standards of correctness apply. Any > enhancements needed by the DPDK core will need to go into the Windows > EAL as currently. All that the patch does is provide the flexibility to > use an external library to provide part of the functionality of the EAL > if the environment requires it (for example to fit with the > application's threading model). Yes, I agree with you that the patch doesn't change any dependencies for DPDK core. It does, however, enable someone to submit patches that relies on external library dependencies, without that being obvious in the patch submission. Since I am not too familiar with DPDK patch submission process, I think we just need to confirm at the next Windows DPDK community call (or on this thread) that "the same standards of correctness apply" means patches are tested to compile on all supported platforms without any special flag, before they are accepted. Khoa.
