From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; Thu, 20 May 2021 17:06:10 +0200 (CEST)
Received: by mail-lf1-f46.google.com with SMTP id j6so22352582lfr.11
 for <dev@dpdk.org>; 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 <dmitry.kozliuk@gmail.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: dev@dpdk.org, Pallavi Kadam <pallavi.kadam@intel.com>, Dmitry Malloy
 <dmitrym@microsoft.com>, Narcisa Ana Maria Vasile
 <navasile@linux.microsoft.com>, Ray Kinsella <mdr@ashroe.eu>, Neil Horman
 <nhorman@tuxdriver.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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.