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 CC6D9A0561; Thu, 4 Mar 2021 08:09:34 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 51B6B40684; Thu, 4 Mar 2021 08:09:34 +0100 (CET) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) by mails.dpdk.org (Postfix) with ESMTP id 3F7AB40147 for ; Thu, 4 Mar 2021 08:09:32 +0100 (CET) Received: by mail-lj1-f181.google.com with SMTP id t9so2858001ljt.8 for ; Wed, 03 Mar 2021 23:09:32 -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=Ni4cZKDRJdGZHaICItAv83PZL0I6/YaZBgEcoqg6+70=; b=YaqTZ8+ra9x9VaesEV7wK5zyfWSeI0vW9w7C28FSbTHGNYA9NaE/TnPtpnjNf4cJE2 e3+TK5p0EokZg+nQTGUMkQq1bv018C+25Am586OYqjEphKEiAwNhuEcGGcPjGq6xBYmk y58WhEI0sTIQv5EmODfSk2B+CagHz9OIRjwuF2EWw05Ns2MDjXvlSDWk146HXHmGLZje Z7v7wR4xm8b1nwjNz+xTlRf1sW+Czo0qh0slNYkyGAnTZRIUZLGeV66QCtXyT4TLmfla jWv7OZQr4BoD/RmyhTvyZ5hTMqFE/mu4CsknRMjR7qjhW3aWal5R9s1StTgJu3tXALV/ bxLg== 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=Ni4cZKDRJdGZHaICItAv83PZL0I6/YaZBgEcoqg6+70=; b=r/q2NzMPjhsIw0pZvb9kMqy9uKt64Jjk9JdNDO+52nr4PC7zk02DS/RXukC+IvyG8s QK87OzitoKbKvCs193/rSLKc83W5kYbItJy6sYpUzDhQ5coD0thU+GmowSAG2jKO5d/T 3d+UJ1Kwbx/xNIiJejyB6JAUkMDZec2eNYvtUViBRfJ2oRR5SW229i+n2V5odDhg8gFK 9HyuJVXagRFJJGlMgN1O7/9IThIx1oALEIV8aibzOL53SiKyM3U2cMQ7wKpYMGuaIHqZ 1kdgyOXoVvp+V/nIhXCTxSyF3Xwa05x/s6Tj1djF/h6N0oFiafZi36QG3jwZQdFoc2SY 6Qsg== X-Gm-Message-State: AOAM532moxa7il6VfCfUtkBZ9iqftagKinm4YRMh2wl5w+59/FRP4qTT PGTbJRJmJ4t/r5qBHmL5u70= X-Google-Smtp-Source: ABdhPJwFGwE5CBtk7swRLsTMyG/fRjbRzvqF2bInaQiwGoPe4O0MA3b6m5M4kWk56jUpi6hQDrFRww== X-Received: by 2002:a2e:921a:: with SMTP id k26mr349576ljg.149.1614841771757; Wed, 03 Mar 2021 23:09:31 -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 b11sm3184726lfd.306.2021.03.03.23.09.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Mar 2021 23:09:30 -0800 (PST) Date: Thu, 4 Mar 2021 10:09:29 +0300 From: Dmitry Kozlyuk To: Stephen Hemminger Cc: dev@dpdk.org, Ferruh Yigit , Pallavi Kadam , Dmitry Malloy , Narcisa Ana Maria Vasile , Ray Kinsella , Neil Horman Message-ID: <20210304100929.7bfacbbe@sovereign> In-Reply-To: <20210303155422.6bead163@hermes.local> References: <20210303225121.16146-1-dmitry.kozliuk@gmail.com> <20210303155422.6bead163@hermes.local> 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-03-03 15:54, Stephen Hemminger: > > + > > +* net: ``s_addr`` and ``d_addr`` fields of ``rte_ether_hdr`` structure > > + will be renamed to ``src_addr`` and ``dst_addr`` respectively in DPDK 20.11 > > + in order to avoid conflict with Windows Sockets headers. > > If those fields were a problem now, there might be others in future. One I can think of is `min` and `max` macros from `windows.h`: they are used as field names in `rte_compressdev.h` and `rte_cryptodev.h` (and more than once have they been worked around in PMD code, see i40e and ice patches). Do you prefer a single notice for all such conflicts we can identify now? > Don't use src_addr and dst_addr because those are already used in rte_ipv4_hdr. Not sure what DPDK policy is: `rte_ipv4/6_hdr` use completely custom names, while `rte_arp_hdr` uses traditional names with `arp_` prefix. Coming from C++, I chose the former approach, but it's not a strong opinion. > Linux and FreeBSD use: > > struct ether_header > { > uint8_t ether_dhost[ETH_ALEN]; /* destination eth addr */ > uint8_t ether_shost[ETH_ALEN]; /* source ether addr */ > uint16_t ether_type; /* packet type ID field */ > } __attribute__ ((__packed__)); > > So why not ether_dhost/ether_shost? Works for me, let's see what others think.