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 00A6EA0526 for ; Tue, 21 Jul 2020 09:37:56 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9A2651C027; Tue, 21 Jul 2020 09:37:55 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150083.outbound.protection.outlook.com [40.107.15.83]) by dpdk.org (Postfix) with ESMTP id 511681BFE7; Tue, 21 Jul 2020 09:37:53 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SxWl1TL+n/qB67NiGVOOka/GI5VmsEpSTFgMKSbMThtQSeo94GIQKhpIO5kXyXo0dNoJ/K30WxiMWTX7oGC/rBwhMyeFLueIKBdrcls2S9wfb1cJF/ALNlzdO1MmSr/wMYdg++B5AkwpwxjP51rDkFUGta9bdpa6oH2ol3/x8Ls8G9PvXcUAFk3CPgMASbUBnzhqJ7t8KurZKbLlz9RZGI8AF/2YLkqnea0gtwc3eLyRLsRbPfpK4Nt6MU0fHo60XyLS5bhgHCzKYTbWgmp155pCPc+uoDPHxKF/eRFPVn0eevXvcC23nM8p/olKNEbMmudXtw/weO8oGAAT3/QkLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Up8iqtrS4nGG9nWA/x9JplTGJrrIy00P8rIzdj3Fexg=; b=O5uJ4MbDYOLzdorTc72Xjqf9t4Ez+AJT60zUFq/8nEuQWC+vxqVVfA1tPLfUL0tJt/i2IWzYnGQflv+D/UlVBLde62Y/f/A8byy6VgmDMNYXl+YC8ot69GbNmaITaSklfDrwhFGG1heEVTmIJ9AKH4tiUDXX4toui7Xr3OeRnkXrW7COz+/iLrWFw5ZgdaRoDepibKLO3qcR3AODNnYIo59qVyGnEk2etkS7oWbFsCsdXqK9uo0p/Tt6wokvWHQNkMRMFvB7PuZNEmAX+iy4Hnr3lD3ch7oIBWjkJlPwT3vhu4JEOP5mDCoG29rJN5O1UawMYn6m4jj3vEwp5Eg1wQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mellanox.com; dmarc=pass action=none header.from=mellanox.com; dkim=pass header.d=mellanox.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Up8iqtrS4nGG9nWA/x9JplTGJrrIy00P8rIzdj3Fexg=; b=MbUn7ZPAiQVyzAq2nccAkt44oxONcRlllINnYx6S4CaoerEc6m37e9W1GijOYWzmXxquLoZA0GBbgz3wZXSL/pMhoSSuWhZvA0+r64Fl2LiTzE9RmnQek88IDU8LE2q7Do5pgOGySeYuV7y2KmB1UjgzpEhMm/9rxmP0bQjgKL4= Received: from AM0PR05MB6707.eurprd05.prod.outlook.com (2603:10a6:20b:15b::17) by AM4PR0501MB2721.eurprd05.prod.outlook.com (2603:10a6:200:5d::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.23; Tue, 21 Jul 2020 07:37:52 +0000 Received: from AM0PR05MB6707.eurprd05.prod.outlook.com ([fe80::ecd3:6008:3784:4012]) by AM0PR05MB6707.eurprd05.prod.outlook.com ([fe80::ecd3:6008:3784:4012%5]) with mapi id 15.20.3195.026; Tue, 21 Jul 2020 07:37:52 +0000 From: Raslan Darawsheh To: Olivier Matz , Ferruh Yigit CC: "dev@dpdk.org" , "stable@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] net: fix compilation with pedantic enabled Thread-Index: AQHWW2prhqFNoRFqYEyi0nK3CzOslKkRLpWAgAB2UYCAAAUxcA== Date: Tue, 21 Jul 2020 07:37:51 +0000 Message-ID: References: <1594901556-11826-1-git-send-email-rasland@mellanox.com> <20200721070925.GF5869@platinum> In-Reply-To: <20200721070925.GF5869@platinum> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: 6wind.com; dkim=none (message not signed) header.d=none;6wind.com; dmarc=none action=none header.from=mellanox.com; x-originating-ip: [84.242.49.134] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: fe98c5ce-f647-4b26-9985-08d82d48f999 x-ms-traffictypediagnostic: AM4PR0501MB2721: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JBhIIZONmEiKKY9gyPPuZz40Ss4WPIsjq+nulK99SCNvRS1mmSxrdnk71hRl7yFaHbT3RzKzzWNC1BDXgsj6oxZxH9KaAnJOlT58Y7ymEJlyUcgVqylYxH8dipU261FAktJ5igFA8z5qe9C13/VsI3BZZORBGXY70tBkw1B0s9uzJeggByqrEANLXmNq9pUfa5FiovwTN76cosiET1vXDmX+rKhKNm0wzqwQbbWUyoAjtswvjjP03ekL994WPa9dpda0HcSC9sXh77ZdVx146sN6B1ffy5TULkObRut4IZFpRK3VB+NCnNX1KgPTKIhH3Rm5vzwCBx5B6zpK8+jrmg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR05MB6707.eurprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(39860400002)(396003)(346002)(376002)(5660300002)(186003)(76116006)(66946007)(7696005)(64756008)(66556008)(66476007)(66446008)(4326008)(52536014)(2906002)(86362001)(71200400001)(316002)(9686003)(33656002)(478600001)(8676002)(55016002)(110136005)(54906003)(83380400001)(6506007)(8936002)(26005)(53546011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: wCZB17xRWmFg/NqIxuKG/knN3PGPWKFrN+tXA/58TSTLLcix8QUlcmx8wsL5TIoG0BcPrMxNT74mYfA5YixvA0q0c9/C3K7X7BczZt/7R8UVbSRu60I+TAxB+mXlmrnQiKCvzxQd8Eb3m09kSuE0n5S5lu8ZmXqLI+QGuPncJMEt2GAqYdwTkaEGHLVT+SiQbswItnyMfiKLrgG+VwgL13kHglq34KgGt7lttDgcKPWk7z71IMwDzqel1cO/EZMmh2Zq7VXZwFhgeFlOiCLAzs4/TDn5cxJk8qkJ4wc5S4pans5LztC7G9dXL9H5Ze5eaTMv8RQodJRA/nVR4z9FBjoO4Q/d8eqK9OAsLGtmpHfG39EWxMYZbfKjGXE/SkZAoyOLXFb4/xa8RZUisFPVxcCzQwKsleCsI/zbiMYoYEPmp24Leo6Cznvjk+MTF1ePk8+AzXcH8gOE/5GY3LXEdPS8kAJKWgmW0cZGErgKIlyumrECrxiht6IORDOfwI/e x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR05MB6707.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fe98c5ce-f647-4b26-9985-08d82d48f999 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2020 07:37:51.9930 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Evi5i55F7Wc6ajgw180x2pACkCB6iMtTeTROCgOB62yIdKHBCbr5qP1/DSpyqZtBTnwRcFGl6W9XPhrvbjEMgw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0501MB2721 Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] net: fix compilation with pedantic enabled X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" Hi, > -----Original Message----- > From: Olivier Matz > Sent: Tuesday, July 21, 2020 10:09 AM > To: Ferruh Yigit > Cc: Raslan Darawsheh ; dev@dpdk.org; > stable@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] net: fix compilation with pedantic enable= d >=20 > Hi, >=20 > On Tue, Jul 21, 2020 at 01:05:57AM +0100, Ferruh Yigit wrote: > > On 7/16/2020 1:12 PM, Raslan Darawsheh wrote: > > > when trying to compile rte_mpls with pedantic enabled, > > > it will complain about bit field defintion. > > > error: type of bit-field 'bs' is a GCC extension [-Werror=3Dpedantic] > > > error: type of bit-field 'tc' is a GCC extension [-Werror=3Dpedantic] > > > error: type of bit-field 'tag_lsb' is a GCC extension [-Werror=3Dpeda= ntic] > > ' > > I tried to reproduce by adding to '-pedantic' to 'rte_net.c' (which use= s > > 'rte_mpls.h') but not able to get the warning. Is this happen with spec= ific > > version of the compiler? Yes It happens only with old compilers, maybe I should have mentioned that = in the commit log (my mistake). gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28) > > > > > > > > This fixes the compilation error. > > > > > > Fixes: e480cf487a0d ("net: add MPLS header structure") > > > Cc: olivier.matz@6wind.com > > > Cc: stable@dpdk.org > > > > > > Signed-off-by: Raslan Darawsheh > > > --- > > > lib/librte_net/rte_mpls.h | 12 ++++++------ > > > 1 file changed, 6 insertions(+), 6 deletions(-) > > > > > > diff --git a/lib/librte_net/rte_mpls.h b/lib/librte_net/rte_mpls.h > > > index db91707..ecd1f64 100644 > > > --- a/lib/librte_net/rte_mpls.h > > > +++ b/lib/librte_net/rte_mpls.h > > > @@ -24,13 +24,13 @@ extern "C" { > > > struct rte_mpls_hdr { > > > uint16_t tag_msb; /**< Label(msb). */ > > > #if RTE_BYTE_ORDER =3D=3D RTE_BIG_ENDIAN > > > - uint8_t tag_lsb:4; /**< Label(lsb). */ > > > - uint8_t tc:3; /**< Traffic class. */ > > > - uint8_t bs:1; /**< Bottom of stack. */ > > > + uint32_t tag_lsb:4; /**< Label(lsb). */ > > > + uint32_t tc:3; /**< Traffic class. */ > > > + uint32_t bs:1; /**< Bottom of stack. */ > > > #else > > > - uint8_t bs:1; /**< Bottom of stack. */ > > > - uint8_t tc:3; /**< Traffic class. */ > > > - uint8_t tag_lsb:4; /**< label(lsb) */ > > > + uint32_t bs:1; /**< Bottom of stack. */ > > > + uint32_t tc:3; /**< Traffic class. */ > > > + uint32_t tag_lsb:4; /**< label(lsb) */ > > > #endif > > > uint8_t ttl; /**< Time to live. */ > > > } __rte_packed; > > > > The struct size keeps same after change, do you know if this behavior i= s > part of > > standard and guaranteed? >=20 > I have the same fear. To my understanding and please correct me if I'm wrong, the type of the bit= fields shouldn't change the size of the structure, As long as the bit order is kept the same, and I made a small test for it a= nd checked the size of the struct it gave 4 bytes (sizeof()) with both defi= nitions. >=20 > Would it make sense to add __extension__ instead? We already do that > for gre, for instance. Yes I guess this can work as well, Kindest regards Raslan Darawsheh