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 E810BA0A0A; Thu, 20 May 2021 17:06:12 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 74F7B40143; Thu, 20 May 2021 17:06:12 +0200 (CEST) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by mails.dpdk.org (Postfix) with ESMTP id CD03540041 for ; Thu, 20 May 2021 17:06:10 +0200 (CEST) Received: by mail-lf1-f46.google.com with SMTP id j6so22352582lfr.11 for ; Thu, 20 May 2021 08:06:10 -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=WmuNC/Xby4oJFuCs2G4UWNMawbACJ0IDm7QToGNVUgU=; b=hDw3yAMYwNr/GKSCtIbzX5261dZd7gaYiI7HjgRHkQYdfmbHtsgYX6EYFwvGufiyZJ ATpO87nsP83y/mYZ5GOs9BLtYvNljlHTW3wxrlkgimWTStM64fTSL3hSCdw5BSg2+KKB mI1cCWLP0xt80uTt0ucEQYTmMdJf2JGFgZWzkNWAfMqRALhkjg9ws+IhgpkqVVUvgTER OrXXdk7WerqN00zp70J5WrlWYmOpSlfgxDr1ss+9ro9oYNGWtAJITUld+so13HdyU5h4 W/XYYP2o9QCIsrpy8jRHWJKXMrhiHnFRdNvWOTV9OkgfUQ9vJJpea7yvMCnMt5nZSxS7 yILQ== 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=WmuNC/Xby4oJFuCs2G4UWNMawbACJ0IDm7QToGNVUgU=; b=Oax1UJCSBSWYc3eKYBTduWxE2sYlUAiPI0xwkkPCQk7mgVxDAdvgf6IiK9r6w5UBXu copuwV1LgZy7J5yQJzBj2z04j9wzixqCh8g5uBBoGSe6e5CxxaPkP98/I1ZkXkLvpdbA CY/Pj4WJEUmQ+0gNORAiSdz3F+nT02RGYvfzGN6Rkzd1kENN78+k2VikaZZ9wD7EVqaE 48odCnGBuZuwpc5mRc9R2mbsHIIANeaAWTwb9YJtXvhDZaQYdDCOUK4w56NbM8HM1sUx PoA1Sl7g75Zw9hI5TuBz3irMNeAuJR9CEw+m/7Vx3VrAyEqrS5K08VYgEQOUv/5nV5dj QQdQ== X-Gm-Message-State: AOAM530iQfVZaVFxwYQFXDmYtMbBmBlHYMwMHfbk9/tmohpgnsXgXqGt 1npN/Nbo3xqqdyQdQKNkfvw= X-Google-Smtp-Source: ABdhPJzUU2gAkGX3yOwv9KOSU2z6HDwnrPXkMhC02PbvK6e7Z4K2UWkEpfPhK+DZHCpmtkxjwb4s7Q== X-Received: by 2002:a05:6512:acc:: with SMTP id n12mr3507569lfu.408.1621523170395; Thu, 20 May 2021 08:06:10 -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 c14sm327388lfi.74.2021.05.20.08.06.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 May 2021 08:06:09 -0700 (PDT) Date: Thu, 20 May 2021 18:06:07 +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: <20210520180607.7bd3dd64@sovereign> In-Reply-To: <06b13bfe-667d-6f26-eb7d-f487c5a3f397@intel.com> References: <20210303225121.16146-1-dmitry.kozliuk@gmail.com> <06b13bfe-667d-6f26-eb7d-f487c5a3f397@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 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.