From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id D06BBA09D9; Wed, 11 Nov 2020 16:24:16 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 33A7B2C36; Wed, 11 Nov 2020 16:24:14 +0100 (CET) Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) by dpdk.org (Postfix) with ESMTP id 50F1E2BAB for ; Wed, 11 Nov 2020 16:24:11 +0100 (CET) Received: by mail-wm1-f45.google.com with SMTP id h2so2637002wmm.0 for ; Wed, 11 Nov 2020 07:24:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mayadata-io.20150623.gappssmtp.com; s=20150623; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=S0El6TLNrYo7I8IgDURlzAq+zI/HOcdit8L/jq0nMjs=; b=KZYlwagzN+kTe7m+Gb2M/j5AG910mEbL0T5HDJYYZzHHj2so1xWgdDg4wWYOxOEkwP 3CtkBiqGakTmW/X43Gwt9TUSUqhHrGML2Df98BYsPEbp4W7UPNTC8nrIsDuz7sScDURg hObZo/m1jx7MwSAuiN8wyJmHZMrrPmlFQiMDxwrQJnv6YqnilByIDPslh2TJWJTzoRoy 4ueHf7JNO1JDWaEH6kVSL1ZMB3RVXEk7bHwRQN6oN4IAjui3JLrUWhhWrbFFqbcFfULr pDbcXJFlNzurEX+Uqfn9sIbh6p1kNGx6PD1XHwLdfKgtsbHOYqYTDjsAEtDn5807rYnI u/uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=S0El6TLNrYo7I8IgDURlzAq+zI/HOcdit8L/jq0nMjs=; b=VXDp1nEEHOrAgizpzEW++Z1B9+hvXoAT4fmyBsEWvIs+MM7BGubL+Z4ptnWCy9Mg3E 2c7Wb4jUg++sbBRRugajvDZbljisFEqPxuhWA20XkYkD9gMitasJy7SiRpjzi2vAB2v1 DgHGTu6keW9Dt21p7SIi35iQgIG45wUEPUt92FgskGj7GqeQ89IFBWJ3edyU/kCAky2e KSDqh4/cB124I8crJ+S+jGk8IGMoeHGAZHbxeM0jsfNB5lkyvxZuB0qqMTuedePf5YGp 8NPTzYIilDMRFHA7C6YsrEQWe4hnxagM69JZvpRGXjJ7Q9F/Ktt70z9ATsctAjD5fZ59 tBxQ== X-Gm-Message-State: AOAM531krWErNJw733dHfdTFf+Hf7+GUPATlhhcZnNSIWiy5XVV+3yo7 9l+VBoVkWEDEsOIgFCPoovuaQg== X-Google-Smtp-Source: ABdhPJxG4aePLCbJLpAO9VC+l/pAgELfSXkkDKEpL6tNknvm/5QcfU+2im/JNsfon51ebKMrLYcfGw== X-Received: by 2002:a1c:b0c4:: with SMTP id z187mr1869031wme.113.1605108250044; Wed, 11 Nov 2020 07:24:10 -0800 (PST) Received: from [192.168.0.33] (cpc98320-croy25-2-0-cust77.19-2.cable.virginm.net. [80.235.134.78]) by smtp.gmail.com with ESMTPSA id l16sm2842110wrx.5.2020.11.11.07.24.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Nov 2020 07:24:09 -0800 (PST) From: Nick Connolly X-Google-Original-From: Nick Connolly To: Khoa To , "dev@dpdk.org" Cc: "Dmitry Malloy (MESHCHANINOV)" , Harini Ramakrishnan References: Message-ID: Date: Wed, 11 Nov 2020 15:24:07 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Subject: Re: [dpdk-dev] [EXTERNAL] [RFC] pthread on Windows X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 >> Sent: Monday, November 2, 2020 3:17 AM >> To: Khoa To ; 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 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. > > > > > > > > >