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 601C6A0A0A; Thu, 20 May 2021 17:27:33 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CC45A40143; Thu, 20 May 2021 17:27:32 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id BEE9740041 for ; Thu, 20 May 2021 17:27:31 +0200 (CEST) IronPort-SDR: zbR01PliUySgMOaNB/SuyjWCsKD1wQ5fUuQcgMpcMvvdHm3dv8wjsmOsZBVaPSOkh1mAouzMyD bsTe0pmnLyWQ== X-IronPort-AV: E=McAfee;i="6200,9189,9989"; a="200956554" X-IronPort-AV: E=Sophos;i="5.82,313,1613462400"; d="scan'208";a="200956554" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 May 2021 08:27:29 -0700 IronPort-SDR: Bv44vOD867WM6xvwCJAMtougLWzBpwbPxlOBIbkbGqq9PBc20TkSZ3X4d0aCQ0IgxaTiskpg7t d8jHhPtp31zg== X-IronPort-AV: E=Sophos;i="5.82,313,1613462400"; d="scan'208";a="433938169" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.241.8]) ([10.213.241.8]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 May 2021 08:27:27 -0700 To: Dmitry Kozlyuk Cc: dev@dpdk.org, Pallavi Kadam , Dmitry Malloy , Narcisa Ana Maria Vasile , Ray Kinsella , Neil Horman References: <20210303225121.16146-1-dmitry.kozliuk@gmail.com> <06b13bfe-667d-6f26-eb7d-f487c5a3f397@intel.com> <20210520180607.7bd3dd64@sovereign> From: Ferruh Yigit X-User: ferruhy Message-ID: <038d838f-d973-1fc9-fb8c-706ec39b7704@intel.com> Date: Thu, 20 May 2021 16:27:23 +0100 MIME-Version: 1.0 In-Reply-To: <20210520180607.7bd3dd64@sovereign> Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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" 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;