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 00DB8A0A0A; Thu, 20 May 2021 17:50:58 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 80F2E40143; Thu, 20 May 2021 17:50:58 +0200 (CEST) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by mails.dpdk.org (Postfix) with ESMTP id D064940041 for ; Thu, 20 May 2021 17:50:57 +0200 (CEST) Received: by mail-lf1-f53.google.com with SMTP id v8so20258515lft.8 for ; Thu, 20 May 2021 08:50:57 -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=dKBmyRwmlvjox46IbQ5LzcqSNjCVGTHdf/Dnv6IOZ34=; b=Dt5pEpnJt+4ud7GZeaJ6n6+LbET0ji7HxOaQiLiJ3JAkAP2Rqt6rP99X/QHfNsi1Gk eAYQ1HmIc1b/cCxEWAAL4RZa2g0a5yZ3TiDVWBIyf/5eGHxqGKyQGKZT1JbEZ5GLmYd/ oVvGxA6LZw6eF4woMHWXcw+5YEE6sbAQOcZe0naiRmmGu7YC4Zu1mStD6bOo5rsj7uWm 9ggEx8dp62Y6r62oIqhn6770rfbIDHedq8bXJZE8PNa51xluLitaZZlTuyvlTSimp3TW yKvIqB2vR9fNBmepiswZCDscqivpps+RqrxviwN8VlMfzqwOlb7ykUAN4sVN0dB461YQ 3FiQ== 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=dKBmyRwmlvjox46IbQ5LzcqSNjCVGTHdf/Dnv6IOZ34=; b=CaxY3YnXNLzDOSWiO2ok5b3el+yJBfauFGfYnl3La6AEI9/CG8UfsAJigfLEk+5GP4 B/lW6CM2lzQOiwg5jm78u1VNOlDS/p4DO1R4K9C9+cF93h8CyBEoBlHMYy8LKkDgGNjs E7nrktIRn7ZVs7iryU9HzFD4Qg23XTnIEfCiZYlt89sazrRJbCfvXe/687vI1e3xxWt/ zNY9C1n4nHaSihfTGufCupxDDvDLqODfOIxyKlQHduvtjDTqdpm0OLpSfSdROVbjjShw 8uMMG19PIofjVIrnWzcHCUPYQv+TTjbLorcm514TmexBmigYF1YiY12ruTH2TzFosLdw VZHA== X-Gm-Message-State: AOAM532w44jyK3hxYXGj6WS4g51aTFvBYdjdutSl7BiCSfHlqSsmTxxx i83vA+YG6+icoiUxMBrpD+8= X-Google-Smtp-Source: ABdhPJyFR3JN0/RxBMyrryKz5gvH0Yg3vR3ziJVO6N1UB11UHbCcdaoXzwd0bGeq8/P3LtOCoy8i0g== X-Received: by 2002:ac2:5b12:: with SMTP id v18mr3814006lfn.261.1621525857358; Thu, 20 May 2021 08:50:57 -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 17sm336699lfr.53.2021.05.20.08.50.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 May 2021 08:50:56 -0700 (PDT) Date: Thu, 20 May 2021 18:50:55 +0300 From: Dmitry Kozlyuk To: Ferruh Yigit Cc: dev@dpdk.org, Pallavi Kadam , Dmitry Malloy , Narcisa Ana Maria Vasile , Ray Kinsella , Neil Horman Message-ID: <20210520185055.7646d8fc@sovereign> In-Reply-To: <038d838f-d973-1fc9-fb8c-706ec39b7704@intel.com> References: <20210303225121.16146-1-dmitry.kozliuk@gmail.com> <06b13bfe-667d-6f26-eb7d-f487c5a3f397@intel.com> <20210520180607.7bd3dd64@sovereign> <038d838f-d973-1fc9-fb8c-706ec39b7704@intel.com> X-Mailer: Claws Mail 3.17.6 (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] [PATCH] doc: announce renaming of rte_ether_hdr fields 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-05-20 16:27 (UTC+0100), Ferruh Yigit: > On 5/20/2021 4:06 PM, Dmitry Kozlyuk wrote: > > 2021-05-20 15:24 (UTC+0100), Ferruh Yigit: > >> On 3/3/2021 10:51 PM, Dmitry Kozlyuk wrote: > > [...] > >>> > >>> It is not mandatory to rename `d_addr`, this is for consistency only. > >>> Naming in `rte_ether_hdr` will also resemble `rte_ipv4/6_hdr`. > >>> > >>> Workaround 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) > >>> This can be done for Windows only or for all platforms to save space. > >>> > >>> #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") > >>> > >> > >> What is the problem with the workaround, why we can't live with it? > >> > >> It requires an order in include files, right? > > > > There's no problem except a tricky structure definition with fields that > > violate DPDK coding rules. It works with any include order. > > > > Will fix typos in v3, thanks. > > > > For following case, won't compiler take 's_addr' as macro? > > #include > #include > struct rte_ether_hdr eh; > /* eh.s_addr.addr_bytes[0] = 0; > Yes, it will. The macro will expand to `S_addr.S_un` and compile successfully. In theory, Microsoft can change the definition of `s_addr`, and while I doubt they will, it's a valid concern and a reason to remove workaround in 21.11.