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 44E67A0487 for ; Mon, 1 Jul 2019 16:28:49 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 661BB1B9C1; Mon, 1 Jul 2019 16:28:48 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id C979C1B9BF for ; Mon, 1 Jul 2019 16:28:46 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jul 2019 07:28:41 -0700 X-IronPort-AV: E=Sophos;i="5.63,439,1557212400"; d="scan'208";a="163700180" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.51]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jul 2019 07:28:40 -0700 Date: Mon, 1 Jul 2019 15:28:38 +0100 From: Bruce Richardson To: Olivier Matz Cc: Stephen Hemminger , DPDK Dev List Message-ID: <20190701142837.GA386@bricha3-MOBL.ger.corp.intel.com> References: <20190516155457.4006-1-bruce.richardson@intel.com> <20190701131112.kdz3koexxyou466k@platinum> <20190701133843.GC380@bricha3-MOBL.ger.corp.intel.com> <20190701141430.ahi4z37na6mt37j2@platinum> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190701141430.ahi4z37na6mt37j2@platinum> User-Agent: Mutt/1.11.4 (2019-03-13) 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" On Mon, Jul 01, 2019 at 04:14:30PM +0200, Olivier Matz wrote: > 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. > At this stage, I'm ok with pushing this to 19.11 to follow the official deprecation process.