From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 38AA5A0C41;
Mon, 2 Aug 2021 19:46:21 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id BA78541147;
Mon, 2 Aug 2021 19:46:20 +0200 (CEST)
Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com
[66.111.4.229]) by mails.dpdk.org (Postfix) with ESMTP id 7872F40140
for <dev@dpdk.org>; Mon, 2 Aug 2021 19:46:19 +0200 (CEST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46])
by mailnew.nyi.internal (Postfix) with ESMTP id 811B8580D5D;
Mon, 2 Aug 2021 13:46:16 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
by compute6.internal (MEProxy); Mon, 02 Aug 2021 13:46:16 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
from:to:cc:subject:date:message-id:in-reply-to:references
:mime-version:content-transfer-encoding:content-type; s=fm1; bh=
dwMlc2b/5T78jfaQ4cRUihbvuhfvJXlE52S5hisauAM=; b=imexzQWZYx36juOm
1pdVXeyq9/4uhBdOlARBF+WnGwWBFcjCXjNk8qaHs6zInK1oCbpPucX2hJirvdh1
/xGpnxmS3m3MnnSHj6tb9G7/Xz4wvVHAdQRK3ZF3YwAk9Uv0A1p5Akd0qJnpQQc8
lcauHAm1H0ujbYjvS5eswZsl9eimpKNKnR2emg66ccQJcdAo8mbk+vJJtgpxoxlv
JMW0rC/JXW4785pIZEmS6J32KkVxovRhes290Y/qbn4cb4Us8MH+e3bqYbFdlBpO
VyYAt3qmm3juqfQZyAdicNY6lX0ZXt1xnlg//sUi82SCa/J36uDoe6ZpDjlvOhk4
F8EwTg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:content-transfer-encoding:content-type
:date:from:in-reply-to:message-id:mime-version:references
:subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
:x-sasl-enc; s=fm3; bh=dwMlc2b/5T78jfaQ4cRUihbvuhfvJXlE52S5hisau
AM=; b=n5OnNy8xJlZ7vlIDpvbz8HtpxlG4fKXLK7VZLkhX4Kb9p2A3ZAfcRA4hf
ia0Qtd5+L3wRGycYZZmFA/i7ATUjxvnjyTTCUl/y2wgNvJGwczW6ov1gm/HrHozU
lFUarHeLHI7goZBSunH35f99SxbyfxUQuSgM7tvqaYgeDk2gZh52cDHNrpMEjTdj
cvN/mBNuWriLgoOEXIYBwett6HRAYATsBnGYZkGaQAuA86tvuacGs/vtf6H4v8xT
rMyOYxFJmTHVqN5/dVBNpKImM+WHgUA5U2BRzmaX54PaudJR64k689LWfKv0gh+u
JdByXMpOvnWMBxzWAtTJzPEH1WkpA==
X-ME-Sender: <xms:Zi8IYSghlhe5HQJdljKbaFbBJx8JTUoWyhfmfUtBH5RPLw5KzoG-8A>
<xme:Zi8IYTAqjHXNtK5x8ubjXVoaRIHFcq0LtGW3G_Hkdx85yphawfiF92x7EeEtVBI6L
ebReEkHGO_lkix1_Q>
X-ME-Received: <xmr:Zi8IYaFuNXY2v_ZQOIGaDdN2Z7W3PPuKM5H6bnbm6zLcXxaJe5hlSSLDC0jHb4fHLcrv_I-MB6ZtfddE92_YZTD6bA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddriedvgddutdejucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr
shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg
ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu
ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh
homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth
X-ME-Proxy: <xmx:Zi8IYbQsdDXZ_qQVe3_lMT6gQO1vMEMsQV3dAFEJLJWpZR6VKua2Ww>
<xmx:Zi8IYfyE1Kwj-kMQjNSwvkmBNroQBNN4fNJJX6WG0TDA5lCSGjV0jA>
<xmx:Zi8IYZ6jLSfZ_4MVzBxf0IbiFt92MjXk1eeO_nnK4Mb9D7l9ni3Ifg>
<xmx:aC8IYSq7OyDPXu1_Hygqxl3OGiylh5F2v0oLeCWtolVA1jPaJuSeDw>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
2 Aug 2021 13:46:12 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Cc: dev@dpdk.org, Ferruh Yigit <ferruh.yigit@intel.com>,
Fiona Trahe <fiona.trahe@intel.com>, Khoa To <khot@microsoft.com>,
Ray Kinsella <mdr@ashroe.eu>,
"andrew.rybchenko@oktetlabs.ru" <andrew.rybchenko@oktetlabs.ru>,
"olivier.matz@6wind.com" <olivier.matz@6wind.com>,
"navasile@linux.microsoft.com" <navasile@linux.microsoft.com>,
"pallavi.kadam@intel.com" <pallavi.kadam@intel.com>,
"ranjit.menon@intel.com" <ranjit.menon@intel.com>,
"bruce.richardson@intel.com" <bruce.richardson@intel.com>,
"stephen@networkplumber.org" <stephen@networkplumber.org>,
Akhil Goyal <gakhil@marvell.com>
Date: Mon, 02 Aug 2021 19:46:11 +0200
Message-ID: <10505026.IfYnoXH78b@thomas>
In-Reply-To: <CO6PR18MB4484F301F91721CCB7227B96D8EF9@CO6PR18MB4484.namprd18.prod.outlook.com>
References: <20210520184254.16790-1-dmitry.kozliuk@gmail.com>
<20210802160037.6f8f9c0b@sovereign>
<CO6PR18MB4484F301F91721CCB7227B96D8EF9@CO6PR18MB4484.namprd18.prod.outlook.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v4] doc: announce API changes for
Windows compatibility
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
02/08/2021 15:48, Akhil Goyal:
> > 2021-08-02 12:45 (UTC+0000), Akhil Goyal:
> > > > 21/07/2021 21:55, Dmitry Kozlyuk:
> > > > > Windows headers define `s_addr`, `min`, and `max` as macros.
> > > > > If DPDK headers are included after Windows ones, DPDK structure
> > > > > definitions containing fields with these names get broken (example 1),
> > > > > as well as any usage of such fields (example 2). If DPDK headers
> > > > > undefined these macros, it could break consumer code (example 3).
> > > > > It is proposed to rename structure fields in DPDK, because Win32
> > headers
> > > > > are used more widely than DPDK, as a general-purpose platform
> > compared
> > > > > to domain-specific kit, and are harder to fix because of that.
> > > > > Exact new names are left for further discussion.
> > > > >
> > > > > Example 1:
> > > > >
> > > > > /* in DPDK public header included after windows.h */
> > > > > struct rte_type {
> > > > > int min; /* ERROR: `min` is a macro */
> > > > > };
> > > > >
> > > > > Example 2:
> > > > >
> > > > > #include <rte_ether.h>
> > > > > #include <winsock2.h>
> > > > > struct rte_ether_hdr eh;
> > > > > eh.s_addr.addr_bytes[0] = 0; /* ERROR: `addr_s` is a macro */
> > > > >
> > > > > Example 3:
> > > > >
> > > > > #include <winsock2.h>
> > > > > #include <rte_ether.h>
> > > > > struct in_addr addr;
> > > > > addr.s_addr = 0; /* ERROR: there is no `s_addr` field,
> > > > > and `s_addr` macro is undefined by DPDK. */
> > > > >
> > > > > Commit 6c068dbd9fea ("net: work around s_addr macro on Windows")
> > > > > modified definition of `struct rte_ether_hdr` to avoid the issue.
> > > > > However, the workaround assumes `#define s_addr S_addr.S_un`
> > > > > in Windows headers, which is not a part of official API.
> > > > > It also complicates the definition of `struct rte_ether_hdr`.
> > > > >
> > > > > Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
> > > > > Acked-by: Khoa To <khot@microsoft.com>
[...]
> > > > Acked-by: Thomas Monjalon <thomas@monjalon.net>
> > > >
> > > Can we have a local variable named as min/max?
> > > If not, then I believe it is not a good idea.
> >
> > Yes, except for inline functions in public headers.
> > The only problematic one I know of is this (rte_lru_x86.h):
> >
> > static inline int
> > f_lru_pos(uint64_t lru_list)
> > {
> > __m128i lst = _mm_set_epi64x((uint64_t)-1, lru_list);
> > __m128i min = _mm_minpos_epu16(lst); /* <<< */
> > return _mm_extract_epi16(min, 1);
> > }
> >
> > Fixing it breaks neither API nor ABI, thus no explicit deprecation notice.
> OK,
> Acked-by: Akhil Goyal <gakhil@marvell.com>
Applied, thanks.