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 31C9DA0A0A; Thu, 20 May 2021 18:16:10 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A8DE741108; Thu, 20 May 2021 18:16:07 +0200 (CEST) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) by mails.dpdk.org (Postfix) with ESMTP id CE88541109 for ; Thu, 20 May 2021 18:16:04 +0200 (CEST) Received: by mail-lj1-f181.google.com with SMTP id 131so20458971ljj.3 for ; Thu, 20 May 2021 09:16:04 -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=m4qUfZP4wsVRsTq0czFMOL2K1kWtsplpJmutqVt+wzg=; b=cGiwiTUefCLGnOjpgVMMnyuKxfQAtpK5damb8nejWJO0/LCp0HNgotPqvM7udszFj4 k3A5jgbUrsoaG0p0jFk2Lp+DU8DlHqiqKuhuqZNTSGESz1eaj1yIQ96qYavr50SoRub6 2WE1m1uo+VOD3LpoJ8m06/FQDQjX6oJx8aVZ71amwFkf2Q3nTrfLf2yADEjB5mImgCn9 NHEEUJoj80b9YdPjhsF6DCwh1ScKN1Hsh+axNbp9s9mBUXqp+yMsEpq+ACp6FvlPHuGb +MSyhjLTWDlGbwzjt937pmLPZf69sJaif4Z4pd9HN/DgTcXvHr5JfNQ+OC6pRVhFwN1K dGug== 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=m4qUfZP4wsVRsTq0czFMOL2K1kWtsplpJmutqVt+wzg=; b=Uatoez+10k38atpEupnKkHvUoAQ2OMBReLOaa7Hwia7QYATmSR3qa11Kf4InCOWF6T G1J14R8TmRMWX/C+0On5cd0/NgGP1P8PV4jb9k8do1NCvno3qDxmHt17GE/MQ9xKsO8a liPlIhMQqM6VgHPUJlXcqT4x69QkdnHWCxwqjs+qW3mpe4P3zat8ancpXU31Dog0e3w9 qe9g0cuv6gb9789COMB8PLYYKniEZ/Js9gB2RmSCgWjTl6F0oo9rJpWIiNqDXOCpR2UQ 6xF10Mxpul78OMlC+ljUBXckItpg51yyvAQTWQuCP7176VDmFw4Kl6m5TTZN9+fWWI/i brWA== X-Gm-Message-State: AOAM532VZUc5FK3oXYFTj5p7//zEmY2+13kZS7ZNGLF6pWl5hbt8w2G0 kHplIj1zl/DicVX2jvRN8ueUecBcxIOlzA== X-Google-Smtp-Source: ABdhPJy+BvMBaTttW/3XppMjWM1WlM7MsVCEVika20ajCLmjr+DdrsmYeiFWEwuqYX+7pIm/b+803A== X-Received: by 2002:a05:651c:543:: with SMTP id q3mr3666112ljp.46.1621527364477; Thu, 20 May 2021 09:16:04 -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 j17sm301445ljo.135.2021.05.20.09.16.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 May 2021 09:16:03 -0700 (PDT) Date: Thu, 20 May 2021 19:16:02 +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: <20210520191602.4bd86174@sovereign> In-Reply-To: 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> 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 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. > > > 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. > > >