Re: [dpdk-dev] [EXTERNAL] [RFC] pthread on Windows

[Nick Connolly <nick.connolly@mayadata.io>]

Hi Khoa,

As far as I can see, the DPDK Performance Test Lab at University of New 
Hampshire provides the guarantee that the standard tree will build just 
fine on Windows (https://lab.dpdk.org/results/dashboard/status/) - in 
particular, the Windows-Compile-DPDK-Meson test.

Regards,
Nick

On 03/11/2020 22:34, Khoa To wrote:
> +Dmitry, Harini
>
> Hi Nick,
>
>> -----Original Message-----
>> From: Nick Connolly <nick.connolly@mayadata.io>
>> Sent: Monday, November 2, 2020 3:17 AM
>> To: Khoa To <khot@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-bounces@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.
>
>
>
>
>
>
>
>
>