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 E0393A0A0A; Thu, 20 May 2021 18:25:51 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6C06240143; Thu, 20 May 2021 18:25:51 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by mails.dpdk.org (Postfix) with ESMTP id 828E540041 for ; Thu, 20 May 2021 18:25:48 +0200 (CEST) IronPort-SDR: rTp8wIGOwfk17qRnhzdluryQaVrDjd14auTEzj5BXAIw30kKP8bTFC2o7xID4Va3BlcLxoJ488 iHRfVJC0/Z2Q== X-IronPort-AV: E=McAfee;i="6200,9189,9989"; a="286800306" X-IronPort-AV: E=Sophos;i="5.82,313,1613462400"; d="scan'208";a="286800306" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 May 2021 09:25:22 -0700 IronPort-SDR: n0G5++D8Vz5t/HXElV/W/Zp37By1cR44R/ejuOioqMCXMwEuCTzDkMBau7fV1OtMk0/rfRpCD5 cAEWGyOz2U8Q== X-IronPort-AV: E=Sophos;i="5.82,313,1613462400"; d="scan'208";a="433954908" 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:25:19 -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> <20210520191602.4bd86174@sovereign> From: Ferruh Yigit X-User: ferruhy Message-ID: Date: Thu, 20 May 2021 17:25:16 +0100 MIME-Version: 1.0 In-Reply-To: <20210520191602.4bd86174@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 5:16 PM, Dmitry Kozlyuk wrote: > 2021-05-20 17:04 (UTC+0100), Ferruh Yigit: >> 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? > > Yes, only it's `S_un.S_addr`, sorry for the typo in my explanation. > Both code snippets from commit message compile successfully. > Ah, I was missing the union on the struct, yes it will build, And +1 to deprecation notice and clean the "struct rte_ether_hdr" whenever possible. >> >>> 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. >>> >> >