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 F2076A0524; Fri, 31 Jan 2020 15:17:01 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8A2971C0CA; Fri, 31 Jan 2020 15:17:01 +0100 (CET) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id A78251C0C3 for ; Fri, 31 Jan 2020 15:16:59 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2020 06:16:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,386,1574150400"; d="scan'208";a="230263384" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by orsmga003.jf.intel.com with ESMTP; 31 Jan 2020 06:16:58 -0800 Received: from FMSEDG001.ED.cps.intel.com (10.1.192.133) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 31 Jan 2020 06:16:57 -0800 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.175) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 31 Jan 2020 06:16:57 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g4QqEElRyH5+M8n4IiXJZXj77/UwCohpL/JXFNfF+BqNeYY/lHLQo/ho8fBCmJDmCiygjWm/Nl3MChZ2eF07Blyr6/CoOPOvCwh7RoJNrzV+BLO/xD9xk2qRrk0LfR/B0xlizfzNVSCvlZB9OzZVOh/GAQicNBXt6GsOxc2GFhZjhillMGslLUCSjFPnrGGeeLqP28WVVdQO8/UXli4GGfhUVivYvB566FrHMQjr3c4jNav+3IKbBhr+7rpKz1NOwtZZE62+Jyyl1ZGQW0iPqnYq7Ce033GIPkdLyi018EyEGZ7TWSWxJFjkeIiyRhHaZMZ9ydW2/C8eFCZbFU7mnQ== 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=3uq/DtgCz28+Xq+MCwWUvslx/EW+untph7f3r6Yt7Pg=; b=QZ+xsHails3PVAr3fzZP3HUb1NrRmMIjs7IXytHHJ8APrHWf3QUzyof7fRgDWxP2oEjMnvshLeOqFdh6Tnyk90NM3k3bF3kQRX/+2ejvYdswGi+CQXLFH7y9OmjA0Tr3XwqBfR3ZlqJpran2hTUOiqWKAtG5Zx1mha80jAvCc/kkhgJjzCwTSEWD0rz9YngjsC/fFnqYvhJpOJ01CDUs2Rj+DCRqfNQdkLgEqva/rnhWm18HwPykPG4GNt+qXNdtGTUAWhwhPdW7RMbi+oqKLngfg3IskVLxum2g0hRanqoSx0YcsQPmO5c8rKXO1J8+ZX+5d97BPVplR9Ey8dB3JA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3uq/DtgCz28+Xq+MCwWUvslx/EW+untph7f3r6Yt7Pg=; b=dlJEGB/mr9aHphE73QgAmmHE6yvU1ldB3dGngPqKuKFUqssaFSyfI+JdLUAJM0+A14K9yu3HT9u2oYwtRfDGwbaGjuej1hLXjSCxdd0KmkyKqg099UPy31QonHP1XIOZ+4q2GudY3z3SbcbQ/P+wmqPR8fn3jBCk8e33Htva6LA= Received: from MWHPR11MB1807.namprd11.prod.outlook.com (10.175.55.20) by MWHPR11MB1613.namprd11.prod.outlook.com (10.172.55.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.29; Fri, 31 Jan 2020 14:16:54 +0000 Received: from MWHPR11MB1807.namprd11.prod.outlook.com ([fe80::a842:b7c7:60c2:9b36]) by MWHPR11MB1807.namprd11.prod.outlook.com ([fe80::a842:b7c7:60c2:9b36%5]) with mapi id 15.20.2686.028; Fri, 31 Jan 2020 14:16:54 +0000 From: "Trahe, Fiona" To: Thomas Monjalon , Akhil Goyal , David Marchand , Anoob Joseph , "Kusztal, ArkadiuszX" , "Yigit, Ferruh" CC: "dev@dpdk.org" , "Richardson, Bruce" , "nhorman@tuxdriver.com" , "Mcnamara, John" , "dodji@seketeli.net" , Andrew Rybchenko , "Trahe, Fiona" Thread-Topic: [dpdk-dev] [PATCH v2 4/4] add ABI checks Thread-Index: AQHV1smFGAWDLtMfdkaM/74xTf+RAKgB6XuAgAAHoQCAAB+HAIAAAt+AgAFOQgCAAEVxAIAA3urQ Date: Fri, 31 Jan 2020 14:16:54 +0000 Message-ID: References: <20191220152058.10739-1-david.marchand@redhat.com> <1ef7ca98-cff6-4c5d-5a71-ddbdf893ee73@intel.com> <6121442.K2JlShyGXD@xps> In-Reply-To: <6121442.K2JlShyGXD@xps> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNDMzYmE0MjQtZWFkMy00ZWZlLTlhNjQtZGVmNmU4YjE4ODQ2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiTWVaVE5US01oYm5kazFzaDlcLzR1bnNnVmFwODA0Y3luMmtcL1lPQTRtaUM0RzBuV3FcL2JCelROK1B6Vk83NmttUiJ9 dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.2.0.6 x-ctpclassification: CTP_NT authentication-results: spf=none (sender IP is ) smtp.mailfrom=fiona.trahe@intel.com; x-originating-ip: [192.198.151.162] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2f12a4dc-1d18-4d4c-a3fe-08d7a6583982 x-ms-traffictypediagnostic: MWHPR11MB1613: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 029976C540 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(199004)(189003)(5660300002)(86362001)(2906002)(8936002)(66946007)(66556008)(66476007)(81156014)(6506007)(81166006)(186003)(26005)(498600001)(66446008)(64756008)(107886003)(9686003)(52536014)(33656002)(4326008)(55016002)(8676002)(76116006)(6636002)(54906003)(71200400001)(7696005)(110136005); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR11MB1613; H:MWHPR11MB1807.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /kppPZMufMrSdQsfzCXgG2hgzUIgdeqbM787Z/EEyCDzRTBTz+v9XgVDzy8hir6DBvbDgfHgE1lrBwiZx7yisSqXkduHnjYgzOis8T4yR/SVnhiZ6XplEZV4zF7yPEPOG8Yk5TCJgxbObPjXxNar08NylqmMuaTWDO8CPvFYCecsNlVR5tENGzsSqGNCTJQds6oAsDG0D85cRfZoRu80TMBmMonnwtjQ/HuY4khsdmJLdHjzSJF0pEdTYvyTpBIFds2TkxRZVEXq4PaYafOQ/WioUbFDpra5C+Jqm2MjtWLYVg6kZtV/YuBk0Pge7hmV5/Wtn/SKLYWCNx5e2tImNGdGiVTonpIjYXFE8VB8RwZv+Iggyl3EF1GIVGVweU/zl6LY2leqxhdheDJEAjooXHtDQAFAjOsPRfGqODThRKkDrgeEni3P0lkyt2KwYsIu x-ms-exchange-antispam-messagedata: Zf/C6Z+dj8DTKnSB29iABrTyOyIgE5ViHMlBohYKnd5IJ2a3o3l3GNXul1j2EQe3uHjR59ebMTo3vxqQ0fVRv65510XI+y7WhB08yKjOaB58voyM+63Z+/U279C2yAmJ1V6GlTixA+Dmn3S83KoOLA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2f12a4dc-1d18-4d4c-a3fe-08d7a6583982 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2020 14:16:54.6961 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Lj07T2wecKNPeN18Uadi5Fkzawx/6vQX9ZFlOIFY/qbMnW33AJOWN2GmUi1si6iQvoIfr5dP9Kw2Ed3yjMpWLQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1613 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v2 4/4] add ABI checks 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" Archived-At: List-Archive: > > > I believe these enums will be used only in case of ASYM case which is= experimental. > > > > Independent from being experiment and not, this shouldn't be a problem,= I think > > this is a false positive. > > > > The ABI break can happen when a struct has been shared between the appl= ication > > and the library (DPDK) and the layout of that memory know differently b= y > > application and the library. > > > > Here in all cases, there is no layout/size change. > > > > As to the value changes of the enums, since application compiled with o= ld DPDK, > > it will know only up to '6', 7 and more means invalid to the applicatio= n. So it > > won't send these values also it should ignore these values from library= . Only > > consequence is old application won't able to use new features those new= enums > > provide but that is expected/normal. >=20 > If library give higher value than expected by the application, > if the application uses this value as array index, > there can be an access out of bounds. [Fiona] All asymmetric APIs are experimental so above shouldn't be a proble= m. But for the same issue with sym crypto below, I believe Ferruh's explanatio= n makes sense and I don't see how there can be an API breakage. So if an application hasn't compiled against the new lib it will be still u= sing the old value=20 which will be within bounds. If it's picking up the higher new value from t= he lib it must have been compiled against the lib so shouldn't have problems. There are also no structs on the API which contain arrays using this for si= zing, so I don't see an=20 opportunity for an appl to have a mismatch in memory addresses. =20 > > >> [C]'function int > > >> rte_cryptodev_get_aead_algo_enum(rte_crypto_aead_algorithm*, const > > >> char*)' at rte_cryptodev.c:239:1 has some indirect sub-type changes: > > >> parameter 1 of type 'rte_crypto_aead_algorithm*' has sub-type ch= anges: > > >> in pointed to type 'enum rte_crypto_aead_algorithm' at > > >> rte_crypto_sym.h:346:1: > > >> type size hasn't changed > > >> 1 enumerator insertion: > > >> 'rte_crypto_aead_algorithm::RTE_CRYPTO_AEAD_CHACHA20_POLY1= 305' > > >> value '3' > > >> 1 enumerator change: > > >> 'rte_crypto_aead_algorithm::RTE_CRYPTO_AEAD_LIST_END' from > > >> value '3' to '4' at rte_crypto_sym.h:346:1 > > > > Same as above, no layout change. > > > > >> > > >> > > >> [C]'const char* rte_crypto_aead_algorithm_strings[1]' was changed = at > > >> rte_crypto_sym.h:358:1: > > >> size of symbol (in bytes) changed from 24 to 32 > > >> > > > > The shared memory size changes, but this is global variable in the libr= ary, and > > the values application can request 'RTE_CRYPTO_AEAD_AES_CCM' & > > 'RTE_CRYPTO_AEAD_AES_GCM' is already there, so there is no backward > > compatibility issue here. >=20 > For this one, I don't know what is the breakage. >=20 >=20 > > > +Fiona and Arek > > > > > > We may need to revert the chacha-poly patches. > > > > > > > I don't see any ABI break in this case, can someone explain if I am mis= sing > > anything here? >=20 >=20 >=20 >=20