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 4B471A056A;
	Thu, 11 Mar 2021 00:54:32 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 25A5522A63E;
	Thu, 11 Mar 2021 00:54:32 +0100 (CET)
Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com
 [209.85.167.50]) by mails.dpdk.org (Postfix) with ESMTP id DE997406A2
 for <dev@dpdk.org>; Thu, 11 Mar 2021 00:54:30 +0100 (CET)
Received: by mail-lf1-f50.google.com with SMTP id d3so36565106lfg.10
 for <dev@dpdk.org>; Wed, 10 Mar 2021 15:54:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=u7jCrKz3gKtTyuaw6zp3zbm8oBVcskPYdcgfLk2e78E=;
 b=btGQNImJ0WJzQJfqmlw75LkifUWrIcn1YrvQ2P4z62POgpvOtz1QJOr2ngDAzmMcyR
 Yw7jvfhU/8YFfszljQ3Ghyun7nVvP9niykX51JVAS2lobJRWV6kYOvm4n5jP59A6chPI
 4u9MrdIGHWA6A8yn0IHf437Dmsoibp0H6ogj4FoIrmJYld+JkuYzFjoOvFgHxf30UCJj
 RjNZg7AA2mke1yGAiE8oRL29/wLYKqttoZBfqipBj3/QPY4itjMDApMO/JovK1LY3Zor
 Q+psU4vsCsojXhXRrmmvxtWbmAGjgIXOj+11UH8vFbyKGV3Hf4m3vBMQPzZ2/RcCCwNe
 s/3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=u7jCrKz3gKtTyuaw6zp3zbm8oBVcskPYdcgfLk2e78E=;
 b=IiHf9jnoy0bQy3gGAxFCb37BbEDKOQcv2QMXqGwpp9QaB+/1lcoWMGle2Srt1G8vAK
 Gix0HlQn1qehIFGeDuY1Tu8K1byg9hhb/IOEV4z8QMqnSSgmluyvrOo/bMi3J2/f4QW/
 niakZrLytmGALXZ6X07MVex6kxQ+zFxEbnK1cU+PJ5ndnJeXi/Udd1pEIYZ0xMHlC+L4
 VrbfM/wBB2aTZSdFcRndhDqFUzVNDdR11OI1KrFjNnxMpf2jyTKf2pKyRn6sLfVcY5Ej
 Odvr+Hu+L0REQKPjqb23+ZqZFD6ofoEiVx4MzycuwW3N3GkNEkzVQjqVUBH24yoHc2PD
 BCww==
X-Gm-Message-State: AOAM5313grL0h9tU+n8Ewwm6V/j9WCH3jMM946zLBw/YtN77yRL6o+ms
 2OS82BSgVaKStQ2ZzeplMuwnvA4eUbfoX1zd
X-Google-Smtp-Source: ABdhPJyE2ikxEyTJ93SqJo2EVUuD3mBzv/76Pl1Rx2NOxA61DsgzrcpCBg6ljH/+KfVeMMc7FtdTEw==
X-Received: by 2002:a19:5055:: with SMTP id z21mr560880lfj.297.1615420470180; 
 Wed, 10 Mar 2021 15:54:30 -0800 (PST)
Received: from localhost.localdomain (broadband-37-110-65-23.ip.moscow.rt.ru.
 [37.110.65.23])
 by smtp.gmail.com with ESMTPSA id y3sm259002lfg.6.2021.03.10.15.54.29
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 10 Mar 2021 15:54:29 -0800 (PST)
From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
To: dev@dpdk.org
Cc: Ferruh Yigit <ferruh.yigit@intel.com>,
 Pallavi Kadam <pallavi.kadam@intel.com>,
 Dmitry Malloy <dmitrym@microsoft.com>,
 Narcisa Ana Maria Vasile <navasile@linux.microsoft.com>,
 Stephen Hemminger <stephen@networkplumber.org>,
 Tyler Retzlaff <roretzla@linux.microsoft.com>,
 Declan Doherty <declan.doherty@intel.com>,
 Fiona Trahe <fiona.trahe@intel.com>,
 Ashish Gupta <ashish.gupta@marvell.com>,
 Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>, Ray Kinsella <mdr@ashroe.eu>,
 Neil Horman <nhorman@tuxdriver.com>
Date: Thu, 11 Mar 2021 02:54:21 +0300
Message-Id: <20210310235421.23259-1-dmitry.kozliuk@gmail.com>
X-Mailer: git-send-email 2.29.2
In-Reply-To: <20210303225121.16146-1-dmitry.kozliuk@gmail.com>
References: <20210303225121.16146-1-dmitry.kozliuk@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: [dpdk-dev] [PATCH v2] 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>

Windows socket headers define `s_addr`, `min`, and `max` macros which
break structure definitions containing fields with one of these names.
Undefining those macros would break some consumers as well.

Example 1:

    #include <winsock2.h>
    #include <rte_ether.h>
    struct in_addr addr;
    /* addr.s_addr = 0;     ERROR: s_addr undefined by DPDK */

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 */

It is proposed to rename the conflicting fields on DPDK side,
because Win32 API has wider use and is slower and harder to change.

New names are left unspecified, open suggestions:

* `struct rte_ether_hdr` (by Stephen Hemminger):

    * `s_addr` -> `ether_shost`
    * `d_addr` -> `ether_dhost` (for consistency)

* `struct rte_param_log2_range`, `struct rte_crypto_param_range`:

    * `min` -> `minimum`
    * `max` -> `maximum`

For `s_addr`, a workaround is possible to use it until 21.11.
For `min` and `max`, no workaround seems available. If cryptodev or
compressdev is going to be enabled on Windows before 21.11, the only
option seems to use a new name on Windows (using #ifdef).

Workaround for `s_addr` is to define `struct rte_ether_hdr`
in such a away that it can be used with or without `s_addr` macro
(as defined on Windows):

    #pragma push_macro("s_addr")
    #ifdef s_addr
    #undef s_addr
    #endif

    struct rte_ether_hdr {
        struct rte_ether_addr d_addr; /**< Destination address. */
        RTE_STD_C11
        union {
            struct rte_ether_addr s_addr; /**< Source address. */
            struct {
                struct rte_ether_addr S_un;
                /**< MUST NOT be used directly, only via s_addr */
            } S_addr;
            /**< MUST NOT be used directly, only via s_addr */
        };
        uint16_t ether_type; /**< Frame type. */
    } __rte_aligned(2);

    #pragma pop_macro("s_addr")

Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
---
v2: * Propose to rename all problematic fields identified so far.
    * Leave future names unspecified, no need to promise now.
    * Propose better names for MAC addresses (Stephen Hemminger).

Thread about `s_addr` workaround:
https://mails.dpdk.org/archives/dev/2021-March/200700.html
Tyler Retzlaff confirmed offline that Microsoft took similar approach.

 doc/guides/rel_notes/deprecation.rst | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 64629e0641..854618f091 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -130,3 +130,12 @@ Deprecation Notices
 * cmdline: ``cmdline`` structure will be made opaque to hide platform-specific
   content. On Linux and FreeBSD, supported prior to DPDK 20.11,
   original structure will be kept until DPDK 21.11.
+
+* net: ``s_addr`` and ``d_addr`` fields of ``rte_ether_hdr`` structure
+  will be renamed in DPDK 20.11 to avoid conflict with Windows Sockets headers.
+
+* compressdev: ``min`` and ``max`` fields of ``rte_param_log2_range`` structure
+  will be renamed in DPDK 20.11 to avoid conflict with Windows Sockets headers.
+
+* cryptodev: ``min`` and ``max`` fields of ``rte_crypto_param_range`` structure
+  will be renamed in DPDK 20.11 to avoid conflict with Windows Sockets headers.
-- 
2.29.2