From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1AE2CC2BCA1 for ; Fri, 7 Jun 2019 18:35:22 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id A56B8208C3 for ; Fri, 7 Jun 2019 18:35:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=networkplumber-org.20150623.gappssmtp.com header.i=@networkplumber-org.20150623.gappssmtp.com header.b="PtWQOcJ7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A56B8208C3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=networkplumber.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A58A21BBDB; Fri, 7 Jun 2019 20:35:20 +0200 (CEST) Received: from mail-pg1-f194.google.com (mail-pg1-f194.google.com [209.85.215.194]) by dpdk.org (Postfix) with ESMTP id D5AA21BB9D for ; Fri, 7 Jun 2019 20:35:19 +0200 (CEST) Received: by mail-pg1-f194.google.com with SMTP id 196so1590500pgc.6 for ; Fri, 07 Jun 2019 11:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=T2xWl61SQE5suhk1MF24m7EOUQdUpJGI4UXKYZ06M+U=; b=PtWQOcJ7JYLrEy5vvwN4rcZEfp7pVqj6uGleML+Lpw/NVXcGJHRwxXmgOfVGIqRTYz Q6DKqxEy29OjhbpS2ItYBKqmlJ2ZTilQuREacNw/5quh2gurtES/9DXFya8ZeY/m6Cil OerkSk2+LBf+aHFPKGPuUeCEnirIGAlRktoAXhvq7BL/69mzpMCV16+VTm7XRA/+vaVg Bd98fM/bZMpUokcKXakA50rc9WLGikttUpuw0lOdQWla3MGCqpU6twf2ur+RjjunC4nG HV0FTfpmqEpzp6oME6Y0/9qs14Ckt5xdXx1Nj21hBLZJ2Qb5qg1YHQcUhYDiDNfZS9eC nn1A== 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=T2xWl61SQE5suhk1MF24m7EOUQdUpJGI4UXKYZ06M+U=; b=LH7GnI5DtXOYJ1HuoKxA5b3wDQwYozX2zfih/GuteUlGBbBr/e2NFrVLgz45pW9wUv GSQOygFTksi9al5QPh0p+PDj5jXYyNBCOq9ZZuSbuPl+0jvulxNx8GDIoPXEaAfIZ6a6 Me1ZCIc/Pt1+q4Ri2JeJ19Q87S5wqqsowb1uufISFiYixT7RGvVASu0EhPPLe4n2yikb ghrwRX3pPqtVluPKWLIh33KGJ3dvpiEoNwZ21UBULPTrYagzM28QmK+biUMxXjP+aiSB 15mlVVLBtMzVlr1NrxpA+3WxZX2Ro9/xaUkVDiENwziNDMdmFXsMa5TYVtfLcoL+S0zJ vhjA== X-Gm-Message-State: APjAAAX56bWqp40D2ZFNFCibFZY1mYGEp84wlYuLwMiK0xmguXhPTN6h twNdSvsEtjQgUvqh5HVgnG47Ew== X-Google-Smtp-Source: APXvYqwB7aNJBJlD4NYUb4vneWL/Eu962f9bHZ7L85hhjzaBV2kDhOzw+hFEJByhTMdmmjeN1Aci5g== X-Received: by 2002:a63:5158:: with SMTP id r24mr4328417pgl.79.1559932518966; Fri, 07 Jun 2019 11:35:18 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id u16sm2853727pje.6.2019.06.07.11.35.18 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 07 Jun 2019 11:35:18 -0700 (PDT) Date: Fri, 7 Jun 2019 11:35:12 -0700 From: Stephen Hemminger To: "Ananyev, Konstantin" Cc: "dev@dpdk.org" , "Richardson, Bruce" , Andrew Rybchenko Message-ID: <20190607113512.3a24bff6@hermes.lan> In-Reply-To: <2601191342CEEE43887BDE71AB97725801688E1B70@IRSMSX104.ger.corp.intel.com> References: <20190516180427.17270-1-stephen@networkplumber.org> <20190605180948.22414-1-stephen@networkplumber.org> <20190605180948.22414-6-stephen@networkplumber.org> <2601191342CEEE43887BDE71AB97725801688E1B70@IRSMSX104.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v4 5/8] net/ether: mark ethernet addresses as being 2-byte aligned X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" On Fri, 7 Jun 2019 16:59:32 +0000 "Ananyev, Konstantin" wrote: > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger > > Sent: Wednesday, June 5, 2019 7:10 PM > > To: dev@dpdk.org > > Cc: Richardson, Bruce ; Stephen Hemminger <= stephen@networkplumber.org>; Andrew Rybchenko > > > > Subject: [dpdk-dev] [PATCH v4 5/8] net/ether: mark ethernet addresses a= s being 2-byte aligned > >=20 > > From: Bruce Richardson > >=20 > > When including the rte_ether.h header in applications with warnings > > enabled, a warning was given because of the assumption of 2-byte alignm= ent > > of ethernet addresses when processing them. > >=20 > > .../include/rte_ether.h:149:2: warning: converting a packed =E2=80=98co= nst > > struct ether_addr=E2=80=99 pointer (alignment 1) to a =E2=80=98unalig= ned_uint16_t=E2=80=99 > > {aka =E2=80=98const short unsigned int=E2=80=99} pointer (alignment 2= ) may result in > > an unaligned pointer value [-Waddress-of-packed-member] > > 149 | const unaligned_uint16_t *ea_words =3D (const unaligned_uint16_t= *)ea; > > | ^~~~~ > >=20 > > Since ethernet addresses should always be aligned on a two-byte boundar= y, > > we can just inform the compiler of this assumption to remove the warnin= gs > > and allow us to always access the addresses using 16-bit operations. > >=20 > > Signed-off-by: Bruce Richardson > > Signed-off-by: Stephen Hemminger > > Reviewed-by: Andrew Rybchenko > > --- > > lib/librte_net/rte_ether.h | 11 ++++++----- > > 1 file changed, 6 insertions(+), 5 deletions(-) > >=20 > > diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h > > index feb35a33c94b..d7b76ddf63eb 100644 > > --- a/lib/librte_net/rte_ether.h > > +++ b/lib/librte_net/rte_ether.h > > @@ -58,7 +58,8 @@ extern "C" { > > * See http://standards.ieee.org/regauth/groupmac/tutorial.html > > */ > > struct rte_ether_addr { > > - uint8_t addr_bytes[RTE_ETHER_ADDR_LEN]; /**< Addr bytes in tx order */ > > + uint8_t addr_bytes[RTE_ETHER_ADDR_LEN] __rte_aligned(2); > > + /**< Addr bytes in tx order */ > > } __attribute__((__packed__)); =20 >=20 > Hmm, that would change layout of any struct/union that has struct rte_eth= er_addr inside. > So seems like implicit ABI breakage to me. > Konstantin There was no rte_ether_addr in previous releases.