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.