From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 796BEA0487 for ; Mon, 1 Jul 2019 16:14:37 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2E4731B9BF; Mon, 1 Jul 2019 16:14:36 +0200 (CEST) Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 1E5B01B9B7 for ; Mon, 1 Jul 2019 16:14:34 +0200 (CEST) Received: from lfbn-lil-1-176-160.w90-45.abo.wanadoo.fr ([90.45.26.160] helo=droids-corp.org) by mail.droids-corp.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hhx7h-0007zF-8S; Mon, 01 Jul 2019 16:17:38 +0200 Received: by droids-corp.org (sSMTP sendmail emulation); Mon, 01 Jul 2019 16:14:31 +0200 Date: Mon, 1 Jul 2019 16:14:30 +0200 From: Olivier Matz To: Bruce Richardson Cc: Stephen Hemminger , DPDK Dev List Message-ID: <20190701141430.ahi4z37na6mt37j2@platinum> References: <20190516155457.4006-1-bruce.richardson@intel.com> <20190701131112.kdz3koexxyou466k@platinum> <20190701133843.GC380@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190701133843.GC380@bricha3-MOBL.ger.corp.intel.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH] 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" Hi Bruce, On Mon, Jul 01, 2019 at 02:38:43PM +0100, Bruce Richardson wrote: > On Mon, Jul 01, 2019 at 03:11:12PM +0200, Olivier Matz wrote: > > Hi Bruce, > > > > On Thu, May 16, 2019 at 04:54:57PM +0100, Bruce Richardson wrote: > > > When including the rte_ether.h header in applications with warnings > > > enabled, a warning was given because of the assumption of 2-byte alignment > > > of ethernet addresses when processing them. > > > > > > .../include/rte_ether.h:149:2: warning: converting a packed ‘const > > > struct ether_addr’ pointer (alignment 1) to a ‘unaligned_uint16_t’ > > > {aka ‘const short unsigned int’} pointer (alignment 2) may result in > > > an unaligned pointer value [-Waddress-of-packed-member] > > > 149 | const unaligned_uint16_t *ea_words = (const unaligned_uint16_t *)ea; > > > | ^~~~~ > > > > > > Since ethernet addresses should always be aligned on a two-byte boundary, > > > > I'm a bit reserved about this last assumption. The ethernet address > > structure may be used in a private structure, whose alignment is 1. Are > > we sure that there is no (funny) protocol that carries unaligned > > ethernet addresses? > > > > Shouldn't we change the definition of unaligned_uint16_t instead? > > Or change the rte_is_broadcast_ether_addr() function? > > > > We could, but I believe the correct behaviour is to make the addresses > always 2-byte aligned, unless someone actually has a real-world case where > there is a protocol that doesn't have the data 2-byte aligned. Maybe you missed that part of my previous answer, I'm copy it again here: > Although this is an ABI break, the network structures are all being renamed > in this release, and a deprecation notice was previously posted for it. Yes, but the network renaming is identified in the release note as an API break, not an ABI break. I thought we agreed to limit ABI breakages to cases where there is no other solution. Here, this is surely a "small" ABI breakage, but I suppose there is a way to do differently. If we really want to do that way, it's better to announce it as an ABI break. Olivier