From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7F6C9A0C41; Mon, 2 Aug 2021 15:00:41 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0EBF141147; Mon, 2 Aug 2021 15:00:41 +0200 (CEST) Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) by mails.dpdk.org (Postfix) with ESMTP id 3D88B40140 for ; Mon, 2 Aug 2021 15:00:40 +0200 (CEST) Received: by mail-lj1-f177.google.com with SMTP id r23so23772472lji.3 for ; Mon, 02 Aug 2021 06:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=S+LW/kmZea+ZbUXASxNX3fUQes7F9Hby2TY9UDuMZ3k=; b=tH41JqK4XttfgIRqMxwm/Iq8EjMUf3HNjWFcp5DXKcTVFbPnAYnrxYhmC41Zkyrqqh 3F3JomfIgUZzoXzWWpLEjLBv05R5VXlKNkgpPSHvjFB5zwDWwwuL71/zEKbB13sWrNFW /JVOIWB1FypKeywfu3innzT99U9S8TelC7CAIYz7FV+/Yz5gKMKDoZwHupUwI1I11hTy A+/ZatzfFeHNOBd1fONAC07CHOeUV18NIjwiNnCmNgyRqMNPJaXnUsjT0yU13dtstr1h 5kkGRKC3RQcqK6dP/qfliLNexVymKfQ5f0BilHrsaV0CNsSq6ei2tX9xNUkWtUdtpv48 7G+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=S+LW/kmZea+ZbUXASxNX3fUQes7F9Hby2TY9UDuMZ3k=; b=E4aAFuuOZFRMAlFlN7ZI2Halz1vaq9wZdU922Eu5gVP1in6iMQQ1sC6YVvQ6M6K2oN komOgt85hxhd0oUp4wVyuRwED5ZLHTLzDfRVjYov5chA59Th2DBSC6GabXm2KrH3Ozd5 brEPFzQ9D31oZAcsE6L9jl+32S4s39CEmchdkNS+f02TLNbQidYHO1h6/fWYMRB7bM9V wtun+WaCDa95IlABGmBj/mon7YU57tceYG0Evf2PGaaingrSLMSkxh4XARmWQc9q0pqO ADCTc8qorS+HF+h+w0Pj4Jn+kQ8xOwDOKuw0cH2WizqPZbKCqTl42EpFw2PqRioJI9jp 3YvQ== X-Gm-Message-State: AOAM533PKEkauwNz/PaX3eYO/03AiLtZLIUCLC7xXCIltnQ4xzMRolQZ Yus2PEy8qn7NDWNCVwoSkQY= X-Google-Smtp-Source: ABdhPJykmkyfhoHPqehMihQRMiPA2ei2m5ARSWqDpSJiDzWxGBXrVuwMEFnRDznM0P0zFWq9IGu3Pw== X-Received: by 2002:a2e:3017:: with SMTP id w23mr77136ljw.449.1627909239690; Mon, 02 Aug 2021 06:00:39 -0700 (PDT) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id x22sm954306lfe.16.2021.08.02.06.00.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Aug 2021 06:00:38 -0700 (PDT) Date: Mon, 2 Aug 2021 16:00:37 +0300 From: Dmitry Kozlyuk To: Akhil Goyal Cc: Thomas Monjalon , "dev@dpdk.org" , Ferruh Yigit , Fiona Trahe , Khoa To , Ray Kinsella , "andrew.rybchenko@oktetlabs.ru" , "olivier.matz@6wind.com" , "navasile@linux.microsoft.com" , "pallavi.kadam@intel.com" , "ranjit.menon@intel.com" , "bruce.richardson@intel.com" , "stephen@networkplumber.org" Message-ID: <20210802160037.6f8f9c0b@sovereign> In-Reply-To: References: <20210520184254.16790-1-dmitry.kozliuk@gmail.com> <20210721195557.762726-1-dmitry.kozliuk@gmail.com> <20210721195557.762726-2-dmitry.kozliuk@gmail.com> <9358059.UORW4hmLsd@thomas> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 > > > #include > > > struct rte_ether_hdr eh; > > > eh.s_addr.addr_bytes[0] = 0; /* ERROR: `addr_s` is a macro */ > > > > > > Example 3: > > > > > > #include > > > #include > > > 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 > > > Acked-by: Khoa To > > > --- > > > +* net: ``s_addr`` and ``d_addr`` fields of ``rte_ether_hdr`` structure > > > + will be renamed in DPDK 21.11 to avoid conflict with Windows Sockets > > headers. > > > + > > > +* compressdev: ``min`` and ``max`` fields of ``rte_param_log2_range`` > > structure > > > + will be renamed in DPDK 21.11 to avoid conflict with Windows Sockets > > headers. > > > > The struct rte_param_log2_range should also be renamed to include > > "compress" prefix. > > But as we break the struct API, it is not an issue I guess. > > > > > +* cryptodev: ``min`` and ``max`` fields of ``rte_crypto_param_range`` > > structure > > > + will be renamed in DPDK 21.11 to avoid conflict with Windows Sockets > > headers. > > > > Acked-by: Thomas Monjalon > > > 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.