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 78207A04DB; Tue, 17 Nov 2020 11:51:12 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 583B058C4; Tue, 17 Nov 2020 11:51:10 +0100 (CET) Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) by dpdk.org (Postfix) with ESMTP id 9464C37B1 for ; Tue, 17 Nov 2020 11:51:09 +0100 (CET) Received: by mail-wr1-f47.google.com with SMTP id d12so22646118wrr.13 for ; Tue, 17 Nov 2020 02:51:09 -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=xstPJb1hy6IQ6SjSDNRpmWUkp4CoAogRXQOuAYFN0EY=; b=0ZSaimv1IjOcHdG0fW6NK4rwySiL54OAnHZ8bxY7cu4jakg9eKQ/GGlCndY9IHff2s Vk8JoSMpVJxhj/uF/A0GxtNkh+/SlFAZysS1zfsxXSw5Hh7FjrXhIzvMfhiKCa6TgLdm k5HEOxe3JSWkRk8bpm/ZTrUnBelRsufuqHqGZLjN7o25onFHd/B/P2zMzkqAYAL/oOH5 Wc/bkG4KdF4Czxo5OsDHoGQR1Kczh1JG/q219S7G5wrjgIn/ChwsxR3g9lafzbcFl6s8 AHmaENtwT8hvZEkLFZU+5tLCLB1+yTCJ+AvrC0YTekFxSJFU4oUnskJkuvJO/+BvXzQd 9Uag== 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=xstPJb1hy6IQ6SjSDNRpmWUkp4CoAogRXQOuAYFN0EY=; b=WyhzFoZ0Puakj+F0M16N0THPZ/sWbKz+a/sBiAmfu1hMQ2p7fFqAlRsjqv2YPZubqk LU9vHfY5FnQxD7hjaRHek140sjObX0zbWZLXwsFJYeFpjEQ8BpMF5mrOqwygLwR6Z2UM gNZcUONItpgCXlxuBz4FlKvSWUiiT5ny3t8fnWPXykYzRQq6PnFDXE8pBEHgaqT1Re+i qrB+t65KjLmi+8aYmkE7ySdjTz7Og/1R4lqewi57xA8rGMokOheP6daa1yRUC0I9vfH6 cAXydcjFVjfDMXtLQa5rjeab80YuKbcC13fldXClHElsES2UTPN8F0oOgXcYc85oTWFI NKNg== X-Gm-Message-State: AOAM5318w9u9+MhCpybN3K06RAmd+mQhDrc5becAczf2qurhiiZqTv22 sRSKhqHBuUpH6O+cz/ca9Ya5hQ== X-Google-Smtp-Source: ABdhPJy04yaLjEPmKf6WeXjfn2w0QmXssaZZKnb5VlR9rtKh52qv5lBhN5+HogeLESmz+QdDX8AsPg== X-Received: by 2002:adf:e506:: with SMTP id j6mr24108071wrm.411.1605610267995; Tue, 17 Nov 2020 02:51:07 -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 g20sm2910063wmh.20.2020.11.17.02.51.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Nov 2020 02:51:07 -0800 (PST) From: Nick Connolly X-Google-Original-From: Nick Connolly To: Thomas Monjalon , Tal Shnaiderman Cc: dev@dpdk.org, navasile@linux.microsoft.com, dmitrym@microsoft.com, pallavi.kadam@intel.com, Dmitry Kozlyuk References: <20201114211156.17196-1-talshn@nvidia.com> <20201114222129.15760-1-talshn@nvidia.com> <20201115021323.388f49da@sovereign> <2575505.0jHVfIEzSa@thomas> Message-ID: <92e984ae-23b1-7a44-5d8f-8d699d487115@mayadata.io> Date: Tue, 17 Nov 2020 10:51:05 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <2575505.0jHVfIEzSa@thomas> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Subject: [dpdk-dev] Windows: A fundamental issue (was eal/windows: definition for ETOOMANYREFS errno) 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" Unfortunately, this change has broken the build for SPDK on Windows. To use the DPDK libraries, an application needs to include the rte_* header, which includes rte_os.h via rte_common.h.  The definition of ETOOMANYREFS clashes with the value used when building the SPDK on Windows. The fundamental issue here is how to support missing POSIX/Linux functionality.  If I understand correctly, the EAL should be responsible for providing all such functionality.  The support should be private to the EAL and only exported through rte_* definitions. This means that rte_os.h should not include POSIX/Linux definitions to avoid clashes such as the one seen with this change.  It's clearly not sustainable if applications have to be modified every time we add more Windows support to the DPDK. Note that this is not an isolated issue - most of the definitions in rte_os.h (redefining close, unlink, strdup etc) should not be present if other layers (application, other libraries, etc) are to be able to implement their own POSIX/Linux support. Please can we back this change out until we have a strategy that allows us to make these definitions available for 'internal' use, but prevent them being visible outside of the DPDK tree.  If we can't wrap them with rte_* yet, perhaps the short term solution could be as simple as setting RTE_DEFINE_POSIX when building DPDK code and hiding them if it is not set? Apologies that I didn't spot the issue earlier. Thanks, Nick On 15/11/2020 23:10, Thomas Monjalon wrote: > 15/11/2020 00:13, Dmitry Kozlyuk: >> On Sun, 15 Nov 2020 00:21:29 +0200, Tal Shnaiderman wrote: >>> The ETOOMANYREFS errno is missing from the Windows build. >>> it is used in initialization of flow error structures. >>> >>> The commit will define it with the same error code used by >>> WSAETOOMANYREFS. >>> >>> Signed-off-by: Tal Shnaiderman >>> >>> --- >>> v2: log message fix, apply errno to both Windows builds >>> and remove dependency on winsock2.h [DmitryK] >> Acked-by: Dmitry Kozlyuk > Applied, thanks > >