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 2A4F8A0559; Mon, 16 Mar 2020 13:57:18 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id F2D5425D9; Mon, 16 Mar 2020 13:57:16 +0100 (CET) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id AA53AFEB for ; Mon, 16 Mar 2020 13:57:15 +0100 (CET) IronPort-SDR: XHzwmqRqi18h+l+xNEEP5qLPhk595znpl2PrZWjzrKXHFJtE2OCKEC3AdvDtXJ92MWEmyCpv2e YYcTMyMj+pOQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Mar 2020 05:57:14 -0700 IronPort-SDR: k1VhkNKB3QkuV7kfYKruoCKc6//6mq8qd71sgwjbIbimD0SzBNS0f5XDVJtASEllW+Fv+jprjp TH/SwAFaRvsA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,560,1574150400"; d="scan'208";a="247446512" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga006.jf.intel.com with ESMTP; 16 Mar 2020 05:57:13 -0700 Received: from fmsmsx151.amr.corp.intel.com (10.18.125.4) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 16 Mar 2020 05:57:13 -0700 Received: from FMSEDG002.ED.cps.intel.com (10.1.192.134) by FMSMSX151.amr.corp.intel.com (10.18.125.4) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 16 Mar 2020 05:57:13 -0700 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.177) by edgegateway.intel.com (192.55.55.69) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 16 Mar 2020 05:57:13 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dpKMITsG1GfQ05ifMC/tckErZa8TfdUfHf9NpZAKLvLOe2x9d3xjjQBIb71bDUjp3xDGQNGpDQo4Oj5iEO8JMx9ehYicUQinmZ72Dl61VUEsHaQiLYfroiMU24MpAMqV7zh5b6kWjCtMKl4tQu1HPQn2zYntHeErmfK9NnpCxdwuqD9CgUd5Czzx12qAeuRJMY79WVqys53Y6rwDW3inT2F5zROpBaDLIqUkSvcbRJwrChoITIEnE/U/k2FApabEA3n3HNHDdR/8uP2Z734kUGO12A3bbkxE4PvCYrofDikciN+wCGeI/zq87bLHn8tHGRoq9q4/9iSPs91UFksZZA== 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=HweNw9CD1GPqGvZHGMsw5SQ0LWwcZ+rHlqxHaGMInVM=; b=FqKlWVsR2t3OvBgL53EI0DKNTIrXniv0+zV4eM/CQcdUDgK7DOmJGYG2qstnz98WUnAnVRiDnrQMmoihnAHYKyvdBe8Kk/EqVx+x2rtZkeILK8h7+9n2fZ4dnUsGo6cDggVgtVXnPGEKAUyG3uGVmsIu3gRx5jU/oOSv9hPJZTQSuCHn15U+nCw/3tOSRGPLnSWMYXDkIQTCTZoGaHpds2mwEtwjggwbJeDjQWuAFoalZ8HQ9Br2606vAq+FSH42N0IxL61OLNkmM8JgnRaqAuSeCJzCDB4w0GoLomZqmh3vYHElrTnnR53xkMCm5Et9vCN7P9splxcRoCa+xsgP+g== 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=HweNw9CD1GPqGvZHGMsw5SQ0LWwcZ+rHlqxHaGMInVM=; b=bmWRo0M8LRGUbb110CQSMkatcqCb7xclLrxECXYdzE0nZmymecEFNfVqUI4d3DN69KoT4179ZqZqB3lNpxoldle4UyKStYLKU7XL3HLW3LZvHrfU4T7fjBSSWD7L62Yqomox1O3YnCSChfSLJGUjfKjLvYfYK+kQ+qXrYFzikEE= Received: from BN6PR11MB1796.namprd11.prod.outlook.com (2603:10b6:404:103::8) by BN6PR11MB3972.namprd11.prod.outlook.com (2603:10b6:405:7f::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.22; Mon, 16 Mar 2020 12:57:11 +0000 Received: from BN6PR11MB1796.namprd11.prod.outlook.com ([fe80::4519:125f:2122:de07]) by BN6PR11MB1796.namprd11.prod.outlook.com ([fe80::4519:125f:2122:de07%3]) with mapi id 15.20.2814.021; Mon, 16 Mar 2020 12:57:11 +0000 From: "Trahe, Fiona" To: "Kusztal, ArkadiuszX" , Thomas Monjalon CC: David Marchand , "nhorman@tuxdriver.com" , "bluca@debian.org" , "ktraynor@redhat.com" , Ray Kinsella , "dev@dpdk.org" , Akhil Goyal , "Yigit, Ferruh" , "Ananyev, Konstantin" , "dev@dpdk.org" , Anoob Joseph , "Richardson, Bruce" , "Mcnamara, John" , "dodji@seketeli.net" , Andrew Rybchenko , "aconole@redhat.com" , "Trahe, Fiona" Thread-Topic: [dpdk-dev] [PATCH v2 4/4] add ABI checks Thread-Index: AQHV1smFGAWDLtMfdkaM/74xTf+RAKgB6XuAgAAHoQCAAB+HAIAAAt+AgAFOQgCAAEVxAIAA3urQgANfUACAABrKgIABOz0AgACAVwCAAAb/gIAAFsaAgAAktQCAAN6iAIAAJLJQgAAxliCAAAdmAIAAGrIwgA33SYCAMiZmIA== Date: Mon, 16 Mar 2020 12:57:11 +0000 Message-ID: References: <20191220152058.10739-1-david.marchand@redhat.com> <7712335.T7Z3S40VBb@xps> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.2.0.6 authentication-results: spf=none (sender IP is ) smtp.mailfrom=fiona.trahe@intel.com; x-originating-ip: [192.198.151.184] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b24a3d14-a7e9-4124-49b6-08d7c9a98b02 x-ms-traffictypediagnostic: BN6PR11MB3972: 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:9508; x-forefront-prvs: 03449D5DD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(346002)(136003)(376002)(39860400002)(199004)(2906002)(316002)(9686003)(54906003)(55016002)(110136005)(71200400001)(186003)(26005)(66446008)(64756008)(81166006)(81156014)(66476007)(8676002)(8936002)(76116006)(66946007)(7416002)(86362001)(4326008)(66556008)(53546011)(7696005)(478600001)(33656002)(6506007)(5660300002)(52536014)(107886003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR11MB3972; H:BN6PR11MB1796.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gEq+bGmQ1IQQU+MFcCQb/+pz9JPKrX7VF4xsU7c2lzTwqHjblLtAyf4ucFIgzxI+WMPmibP5pBCLneqUtw4RyS8KHAIFbbzn1jOQsgNzL4QjHIIx05E2PUwdYfNAy+gJWn9oEZrNOF4C6Ts7iUM5HMOC30zVLJEEUc5eUs0Nx/8154NtuHfeTlRpprAPz1FUDPyo/0QH7uOzbmo10J9Uf0vgKhdWm+BVSab4wKMvLSKFZq3Z3CnJ/HC+Do6/phhlu4mbLw0n+qa3S+DIyPqwVQ2OSU/ZBBZGWHW1JEW33KwTCW7p2EPXmu0QViE6WwRi4sL1w39rhMDN7rgYsQ/rduFJRhcpV+2MVbvZPNzPMuvtLqMjFo8RfZBkk2699fXrmC4u7SYmiz8UOxI9pFIyexe8KFBxpwhkg0D5zWWSYteRvGc+L6qNatXNqpMfzFQu x-ms-exchange-antispam-messagedata: blRRE6CeBAPTR/9XCwZzRzg1jhaZT6+1vr+vW6cMJMWO88xZ9ea0Nx5AqpSxbCFfyqtGi1BTmLyAmfW3grk4xwcimIqnHNtheIHK6lOl8sLl8u/WGIjDHApksxVgd677gxA95yeUm4xKzra43RdFHw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b24a3d14-a7e9-4124-49b6-08d7c9a98b02 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2020 12:57:11.2564 (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: qhEiOwq5qD9yXjjFih437Qatfia3wWj9arkitIlZkePCIegPnMw/NN2eFvjFr3MVq+8BOnNLz+PUX8cx/8znYQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB3972 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" Hi, > -----Original Message----- > From: Kusztal, ArkadiuszX > Sent: Thursday, February 13, 2020 2:51 PM > To: Trahe, Fiona ; Thomas Monjalon > Cc: David Marchand ; nhorman@tuxdriver.com; bl= uca@debian.org; > ktraynor@redhat.com; Ray Kinsella ; dev@dpdk.org; Akhil Go= yal > ; Yigit, Ferruh ; Ananyev, K= onstantin > ; dev@dpdk.org; Anoob Joseph ; > Richardson, Bruce ; Mcnamara, John ; > dodji@seketeli.net; Andrew Rybchenko ; aconole= @redhat.com > Subject: RE: [dpdk-dev] [PATCH v2 4/4] add ABI checks >=20 > Hi, >=20 > Two comments from me, >=20 > > > > The patch we're working on will provide two versions of > > > > rte_cryptodev_info_get(), both call the same PMD function from the > > dev_ops info_get fn ptr. > > > > The default version operates s as normal, the 19.11 version searche= s > > > > through the list returned by the PMD, looking for sym.aead.algo =3D > > > > ChaChaPoly, it needs to strip it from > > > the list. > > > > As PMDs just pass a ptr to their capabilities list ( it isn't a > > > > linked list, but an array with an end marker =3D > > > > RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST) if the API layer detects > > > > Chacha it must allocate some space and store a local copy of the tr= immed > > list. This must be stored only once per device. > [Arek] The problem with this solution is that we need to allocate memory. > So the question is how to handle unlikely case of malloc error when we op= erate inside void function > rte_cryptodev_info_get? > And even if we would pass somehow error condition to the caller then what= to do is another question. [Fiona] Quick recap: To avoid breaking ABI, we must return a set of capabil= ities with/without ChaChaPoly depending on the appl version. To resolve this, within the rte_cryptodev la= yer, we propose to=20 inspect the capabilities returned by PMD and strip ChaCha if it exists. In that case memory for the new trimmed capabilities array has to be malloc= ed by the lib. All good, except how to handle a malloc fail is yet another API breakage as= rte_cryptodev_get_info() returns void. We propose to return an empty capability list, i.e. a list with only the EN= D element (which can be done without malloc)=20 in this corner case of a corner case. Anyone see any issue with this? >=20 > > > > > > I don't understand what you have to store. > > > Can't you just set the algo to 0 if it is ChaCha? > > [Fiona] it returns a pointer to data in the PMD domain, which the API c= ouldn't > > and shouldn't overwrite, e.g. > > static const struct rte_cryptodev_capabilities qat_gen3_sym_capabilitie= s[] > Should we print user some information > > > > > > > > > This versioning will apply to any PMD which wants to take advantage > > > > of the new API between now and > > > 20.11. > > > > > > > > Note, I expect the ABI checker tools will still complain of ABI > > > > breakage as the LIST_END value will still > > > change. > > > > > > Right, you need to update the ignore list for the tool. > > > > > > > We are also reviewing all other cryptodev APIs in case there is any= other > > API which needs versioning. > > > > > > > > Anyone see any problem with this approach? > > > > > > The other issue is with all other functions accepting this enum as in= put. > > > We should continue returning an error if getting Chacha as input with > > > 19.11 version of these functions. > > > But I would tend to consider this small ABI breakage can be ignored a= s > > > it is in the error path. > > [Fiona] The QAT PMD tests for and handles this error. I expect other PM= Ds > > do too. > [Arek] - Yes, it is error path but on the other hand we explicitly specif= y what value we will return when > calling > rte_cryptodev_sym_session_init so caller may expect EINVAL when wrong alg= orithm value selected > (usually it probably will be ENOTSUP). > In this case when setting 3 (LIST_END) on 19.11 app and linking against 2= 0.02 (assuming with Chacha) > shared build, caller would get success on return and fully set chacha ses= sion, > which will probably result in undefined behavior. > So shouldn't this function be versioned as well then? [Fiona] I would agree with Tomas to ignore this small ABI break, as it is a= lready an error case if a appl is passing in a bad value for the algorithm. Even if it does retu= rn SUCCESS, instead of ENOTSUP, what behaviour could the application be expecting with a session using LIS= T_END as an algo? >=20 > Regards, > Arek >=20 >=20