From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 44E67A0487 for <public@inbox.dpdk.org>; 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 <dev@dpdk.org>; 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 <bruce.richardson@intel.com> To: Olivier Matz <olivier.matz@6wind.com> Cc: Stephen Hemminger <stephen@networkplumber.org>, DPDK Dev List <dev@dpdk.org> 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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> 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.