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 5B17CA0A0A; Thu, 20 May 2021 18:04:57 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CAB7A40143; Thu, 20 May 2021 18:04:56 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id C310E40041 for ; Thu, 20 May 2021 18:04:54 +0200 (CEST) IronPort-SDR: WKA2cbI66Gx9+3voUBlz/0WCFWnSIe9xMII8FocXXXMGEAoj9edRrrbkDT97PabEa2CK1Ypkq8 nfxvH4ZPZH9A== X-IronPort-AV: E=McAfee;i="6200,9189,9989"; a="201304119" X-IronPort-AV: E=Sophos;i="5.82,313,1613462400"; d="scan'208";a="201304119" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 May 2021 09:04:11 -0700 IronPort-SDR: 64emF/72Xz1DrynGv1CfM3BqwnrhpfSlrdRlr4aeSBuTTwFTS4vMxO6AvBkoF01IF4rnSAjHy/ JlGMN9sWnfPw== X-IronPort-AV: E=Sophos;i="5.82,313,1613462400"; d="scan'208";a="433947688" 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 09:04:08 -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> <038d838f-d973-1fc9-fb8c-706ec39b7704@intel.com> <20210520185055.7646d8fc@sovereign> From: Ferruh Yigit X-User: ferruhy Message-ID: Date: Thu, 20 May 2021 17:04:06 +0100 MIME-Version: 1.0 In-Reply-To: <20210520185055.7646d8fc@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:50 PM, Dmitry Kozlyuk wrote: > 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. will 'eh.S_addr.S_un.addr_bytes[0] = 0;' 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. >