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 83A24A0561; Wed, 3 Mar 2021 19:19:25 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3D8EC16071D; Wed, 3 Mar 2021 19:19:25 +0100 (CET) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by mails.dpdk.org (Postfix) with ESMTP id 2DEA240683 for ; Wed, 3 Mar 2021 19:19:24 +0100 (CET) Received: by mail-lf1-f53.google.com with SMTP id z11so38584159lfb.9 for ; Wed, 03 Mar 2021 10:19:24 -0800 (PST) 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=NoomICA7LK4/3kScXsvIG3BX28qK/EVr+2EU7RsdBtU=; b=HGAYPX6WBXDbYfbtzmlf+2ilfsiYd6yXUsDy6GN+CMXMJhasoPxTy03NtSBIkmuFlj OGYpcAhMz+rlfgqBUZLfkWaQTTx+0Y+PiAGNvQ2sfrtv67kdwcq40C/tu61p2gf9Bgzd 3imlLc2e/RH+oei3A9g9Spp2NEAuUV13rqYE/4R/FBIR3lvqzTABVcmPiMdvbeMfZcKf nCccO8jIzg9us9wwYAqdrHKeqpYjtI3QPfJsuEALUnmnvetHhKGvnA+zBh6hXl2ehwM2 2lmLtZz+fIHLjfc+85UuwZg9WCK7zbLl+DtEmP/45b91Lhy8hArqWNy6zdBM/gh7VrYz m+jQ== 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=NoomICA7LK4/3kScXsvIG3BX28qK/EVr+2EU7RsdBtU=; b=aN4fircaAgJsq7Ee5N8OsIz95Hbrfkll7TDO+EN270p6tancJKLmgWBJkH0SYIr5nr KMZ5mYVOd75+paaRr/r6RSbLpJ+ba1Phy3i4kzlLDs8cDBWIJ3l0cKL8HelgCOll89vk /JQnt7efWU/Rv83ewGvLekAHWCjQxuaGO1mPCrtd6ZXE3l2YdKgGFEuIAJm7uNX9taYp il545FVGmlOc/x1zRcP6C8FLSrj39gCJ90e5Mb7jFc084gxfoseYMUTa921404AYSOqG JeXMD1b3DRNc/PRhaPdCPSWLV76y+7AB/xzp3widGYOlGgw4aVX6s4zZG+eX9z5n1LIc e0dg== X-Gm-Message-State: AOAM530NOd4vK3n2RdolQO5XsgykOg8N+9TWHJa729JFsuY04+61QbWz JABQsxwNSNEYCQniSG3rNqU= X-Google-Smtp-Source: ABdhPJz6TqJPs4kygLL0d7NiQ50Th30VF2NKUbLuZ+YMV4pTvf+UJaiLOSH4xTuWcZYXuBd7CrOn2w== X-Received: by 2002:ac2:5ec2:: with SMTP id d2mr16419lfq.214.1614795563506; Wed, 03 Mar 2021 10:19:23 -0800 (PST) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id c25sm1064469lfr.105.2021.03.03.10.19.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Mar 2021 10:19:22 -0800 (PST) Date: Wed, 3 Mar 2021 21:19:20 +0300 From: Dmitry Kozlyuk To: Ferruh Yigit , Tyler Retzlaff Cc: Nick Connolly , dev@dpdk.org, Mike Wells , Narcisa Ana Maria Vasile , Dmitry Malloy , Pallavi Kadam , Jie Zhou Message-ID: <20210303211920.59ad403d@sovereign> In-Reply-To: References: <20210214012013.23165-1-dmitry.kozliuk@gmail.com> <20210214021616.26970-1-dmitry.kozliuk@gmail.com> <20210214021616.26970-5-dmitry.kozliuk@gmail.com> <6c5e9d34-abfa-d808-eef0-165315baf3ce@intel.com> <20210225220440.2bda87c3@sovereign> <20210226021001.73829588@sovereign> <826eb0d3-3c0b-7581-99be-77e9bb6e8fa2@mayadata.io> <20210302020559.6d3317d7@sovereign> <65bd9188-0fcd-ab0c-2434-6a298be19b1a@mayadata.io> <20210303193240.2b83d9c9@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 v2 4/6] net/pcap: add libpcap wrappers 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-03-03 16:47, Ferruh Yigit: > On 3/3/2021 4:32 PM, Dmitry Kozlyuk wrote: [...] > > If we can't help including / from public headers, > > might as well use `struct in_addr`, just replace `#include ` > > with `#include ` everywhere. > > > > The only remaining issue will be `s_addr` macro on Windows that conflicts with > > `struct rte_ether_addr` field `s_addr`. I don't know a better solution than > > renaming `s_addr` to `src_addr` in DPDK (OTOH, it will be consistent with > > `struct rte_ipvX_hdr` field naming). > > > > Ferruh, what do you think? > > > > No problem on the chosen name, that will work fine, but the 'struct > rte_eth_addr' is public struct, we can't rename it without breaking the user > applications. > > Still it is possible to rename public struct, but it is a long process, need to > send a deprecation notice and wait for next LTS, 21.11. > > Ethernet header already has following, doesn't it help: > #undef s_addr /* Defined in winsock2.h included in windows.h. */ It helps until you do the following: #include /* #define s_addr S_un.S_addr */ #include /* #undef s_addr */ struct in_addr a; a.s_addr = 0; /* ERROR, `s_addr` has been defined to do that */ Or the following: #include #include struct rte_ether_hdr eh; eh.s_addr.addr_bytes[0] = 0; /* ERROR: `addr_s` is a macro */ If you swap include order in each case, it compiles, i.e . code is fragile. Shims redefine `struct in_addr` and we're trying to get rid of them anyway. Here's a solution that always works, however ugly it looks. It defines `struct rte_ether_hdr` for Windows such that `s_addr` macro works for it if defined. We can keep it until 21.11, then remove it and rename fields. In return, we can remove networking shims and workarounds immediately. `S_un.S_addr` part of `struct in_addr` is documented, and thus is unlikely to ever change: https://docs.microsoft.com/en-us/windows/win32/api/winsock2/ns-winsock2-in_addr diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h index 060b63fc9..67d340bb2 100644 --- a/lib/librte_net/rte_ether.h +++ b/lib/librte_net/rte_ether.h @@ -23,10 +23,6 @@ extern "C" { #include #include -#ifdef RTE_EXEC_ENV_WINDOWS /* Workaround conflict with rte_ether_hdr. */ -#undef s_addr /* Defined in winsock2.h included in windows.h. */ -#endif - #define RTE_ETHER_ADDR_LEN 6 /**< Length of Ethernet address. */ #define RTE_ETHER_TYPE_LEN 2 /**< Length of Ethernet type field. */ #define RTE_ETHER_CRC_LEN 4 /**< Length of Ethernet CRC. */ @@ -257,6 +253,8 @@ __rte_experimental int rte_ether_unformat_addr(const char *str, struct rte_ether_addr *eth_addr); +#if !defined RTE_EXEC_ENV_WINDOWS || defined __DOXYGEN__ + /** * Ethernet header: Contains the destination address, source address * and frame type. @@ -267,6 +265,28 @@ struct rte_ether_hdr { uint16_t ether_type; /**< Frame type. */ } __rte_aligned(2); +#else + +#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; + } S_addr; + }; + uint16_t ether_type; /**< Frame type. */ +} __rte_aligned(2); + +#pragma pop_macro("s_addr") +#endif + /** * Ethernet VLAN Header. * Contains the 16-bit VLAN Tag Control Identifier and the Ethernet type