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 90637A0542; Thu, 13 Feb 2020 15:51:39 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6D9B11C013; Thu, 13 Feb 2020 15:51:39 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 224651C00E for <dev@dpdk.org>; Thu, 13 Feb 2020 15:51:37 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2020 06:51:37 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,437,1574150400"; d="scan'208";a="313745650" Received: from orsmsx108.amr.corp.intel.com ([10.22.240.6]) by orsmga001.jf.intel.com with ESMTP; 13 Feb 2020 06:51:36 -0800 Received: from orsmsx603.amr.corp.intel.com (10.22.229.16) by ORSMSX108.amr.corp.intel.com (10.22.240.6) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 13 Feb 2020 06:51:36 -0800 Received: from orsmsx603.amr.corp.intel.com (10.22.229.16) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 13 Feb 2020 06:51:36 -0800 Received: from ORSEDG001.ED.cps.intel.com (10.7.248.4) by orsmsx603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Thu, 13 Feb 2020 06:51:36 -0800 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.168) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 13 Feb 2020 06:51:33 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OMwPskQYtmzaJhR5m7Ong1/GipmICHZzsB+Vp9xGNGDKlCgl+4dtx/xxIifAE+ZxwBwuvJ08tvCLwLeBioHOzf0tei0tZcMowGkjbjI5hqXlCZLQIMKEgIW2cQhP8h9QcRzVuZDcmF4OudIwl1KARnJw3O0Uw6ocBfsqF0KTdLdlBjgA//TIUDgtFJJ75w16cvUnKzPbJ2qYIKyOppn4wrjFeoyazYyKu9vf7T7M317m20HDgfU6RG4NXTD1V2EmIeWk+emJUGxsYAoE1XS0a+21ElZIstVwmILO9sbd3DpLSKbrlVPL+RBWm0NMFWfDd4O3C5RCb09S6tRvKEPZGw== 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=54U2jpSVzgTHOKhUjGJ/mfRFnyp4za7xvz+6lC1K1Oc=; b=i+WbTZo0w5aoYwMn2KPj9bb6/r/GhBEnYjbAx7GaczY6CCiFtyXNStm8r6F1/+C11bq04cExmlk154Am37m56xoqW8swzoGglDudHwR3qjmTKlrpv8lNDK6lUPwDnpGlJSTH7CLajGzhjMcPahDul83tCjgkkbltXI0gw8WoE+8Ra6tfHWurI8Pcvsruwzs5hNlqK+17Rd4N4/ygOGWLUjlsek6j2ENxOK5JXnu60IIyu1PtKCWunw1+YL9dKAvbVLJAe1zrcA0OWQa/+91lPDF67uBYXnrmJ0EgAYqCz7hgV5lvq5KjxUTR39lcTLuUdhlc/vWJiwsjnsp8NMh2Hg== 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=54U2jpSVzgTHOKhUjGJ/mfRFnyp4za7xvz+6lC1K1Oc=; b=jgJbJaiAjz3u2pRMZbpHGSgu3a86HW9n68lE0jqJ3CxOisRqMLgtBvNGDSUjF6JwBrrV4R/1WFyTtBiYHf+olVO0bUL1DnceCM7V8UX5zGmOITv7tTNGBFQtbenXy37Jn7zBTixDSB05yYFaprcibnQYbEvf0qsBjoT05HDoPW0= Received: from BYAPR11MB3831.namprd11.prod.outlook.com (20.178.239.150) by BYAPR11MB2950.namprd11.prod.outlook.com (20.177.227.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.21; Thu, 13 Feb 2020 14:51:30 +0000 Received: from BYAPR11MB3831.namprd11.prod.outlook.com ([fe80::2410:3fa:b1a1:9a3a]) by BYAPR11MB3831.namprd11.prod.outlook.com ([fe80::2410:3fa:b1a1:9a3a%6]) with mapi id 15.20.2729.025; Thu, 13 Feb 2020 14:51:29 +0000 From: "Kusztal, ArkadiuszX" <arkadiuszx.kusztal@intel.com> To: "Trahe, Fiona" <fiona.trahe@intel.com>, Thomas Monjalon <thomas@monjalon.net> CC: David Marchand <david.marchand@redhat.com>, "nhorman@tuxdriver.com" <nhorman@tuxdriver.com>, "bluca@debian.org" <bluca@debian.org>, "ktraynor@redhat.com" <ktraynor@redhat.com>, Ray Kinsella <mdr@ashroe.eu>, "dev@dpdk.org" <dev@dpdk.org>, Akhil Goyal <akhil.goyal@nxp.com>, "Yigit, Ferruh" <ferruh.yigit@intel.com>, "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, "dev@dpdk.org" <dev@dpdk.org>, Anoob Joseph <anoobj@marvell.com>, "Richardson, Bruce" <bruce.richardson@intel.com>, "Mcnamara, John" <john.mcnamara@intel.com>, "dodji@seketeli.net" <dodji@seketeli.net>, Andrew Rybchenko <arybchenko@solarflare.com>, "aconole@redhat.com" <aconole@redhat.com> Thread-Topic: [dpdk-dev] [PATCH v2 4/4] add ABI checks Thread-Index: AQHV1sl6v2NXnfoHmkOb0gtPonzveKgB6XuAgAAHogCAAB+GAIAAAuCAgAFOQQCAAEVxAIABLWUAgAMQ1QCAABrKgIABOz4AgACAVgCAAAb/gIAAFsaAgAAktQCAAN6iAIAAJxkAgAA0qgCAAAHrAIAAHfYAgA3YuCA= Date: Thu, 13 Feb 2020 14:51:29 +0000 Message-ID: <BYAPR11MB383131CC805B304940E632B39F1A0@BYAPR11MB3831.namprd11.prod.outlook.com> References: <20191220152058.10739-1-david.marchand@redhat.com> <BN6PR11MB179692C72753461896CB9B11E4030@BN6PR11MB1796.namprd11.prod.outlook.com> <BN6PR11MB179688305FF722D57FEBF62FE4030@BN6PR11MB1796.namprd11.prod.outlook.com> <7712335.T7Z3S40VBb@xps> <BN6PR11MB17961C321FB6446CE9440C88E4030@BN6PR11MB1796.namprd11.prod.outlook.com> In-Reply-To: <BN6PR11MB17961C321FB6446CE9440C88E4030@BN6PR11MB1796.namprd11.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.2.0.6 dlp-product: dlpe-windows x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMTliNWY4ZjUtMWIxMy00ZjJkLWFlNTEtNjE4M2Q1MzNiODg5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiSXZDQmJKMGttUDQwNXR1THJadFJ3VEZcL0xkV1JCMlBSeTV1aEx6TEE0RmlzazF2U3NOTkgrUnhSTUljVFBBaVMifQ== authentication-results: spf=none (sender IP is ) smtp.mailfrom=arkadiuszx.kusztal@intel.com; x-originating-ip: [134.191.221.72] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: af941920-8470-47b4-8fc2-08d7b09435b7 x-ms-traffictypediagnostic: BYAPR11MB2950: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: <BYAPR11MB29500F07C11C65B21E349C4C9F1A0@BYAPR11MB2950.namprd11.prod.outlook.com> x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 031257FE13 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(396003)(376002)(346002)(136003)(199004)(189003)(316002)(54906003)(66446008)(66476007)(52536014)(64756008)(66946007)(71200400001)(66556008)(5660300002)(76116006)(55016002)(110136005)(8936002)(478600001)(7416002)(9686003)(81166006)(81156014)(8676002)(33656002)(2906002)(6506007)(26005)(7696005)(186003)(86362001)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR11MB2950; H:BYAPR11MB3831.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: GDc1rnlmn0HaQgDkjpTA868P7eIPfU3spYyXNZQipQwkfMC9OZ0eRalZb3vvvrR2pB2+ZTy8SGNnAT33tJNf+ZN3h6Myb4rFrJF4g8c0HphGvq5g3CrCqxzKHckyLFN2ciiEQukZdVknUESl5S1RsyPyzqX9JOEBlwEPSj/7RRU1zak9ibUPlEoZZxTtxktX0kSQXWHwGh81ed6zqBPOSHCGZIv5RF+La8fU5Jdi40BWhSFfB4nrNDKqNwKFTVaZzwTgjPG/qWluHMuUM47NkPBoig4WM0Xw3Bmdip4rGqfmnFIQaU3l3ByLSGEe03FHSo4mwNzsFwKni0PMe5+3KEE8UKiBQ2rmu/tAp3FbMKb/6jfZ0YR5fLPwnOtUNXCaPUQzyaUdFxHvBqBXDl6X4pTSIW8/QHvaiYoooKlkmNCwMOzcpgIvidoIto4iPn/T x-ms-exchange-antispam-messagedata: jm5UDJtwUeAea2VflecIxbRGcz3lKQ1fSN/ngij4dCYTHzIyrpMJ+ksrfsRvNNiV3mQhxzi3SkR/11Z67O5D5Dy0wMIruY536a0tgZgWUsuBiUU/4/j25JvjUY2AWLXXA2dmwsoAHfXCyolFPjUV+g== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: af941920-8470-47b4-8fc2-08d7b09435b7 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2020 14:51:29.7266 (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: l3w0wjluq7eIqlcr6MKe8grZmPXrcLqSUaoPEz/yXbDYb1eLO1RiEIoW+F2h9Dc7EqzNTMJrbZoUe+bZ7NESf2d2O5+LmC2VRhgk/8bteEk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2950 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 <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> Hi, Two comments from me, > > > 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 searches > > > 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 trim= med > list. This must be stored only once per device.=20 [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 oper= ate inside void function rte_cryptodev_info_get? And even if we would pass somehow error condition to the caller then what t= o do is another question. > > > > 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 cou= ldn't > and shouldn't overwrite, e.g. > static const struct rte_cryptodev_capabilities qat_gen3_sym_capabilities[= ] Should we print user some information >=20 > > > > > 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 o= ther > API which needs versioning. > > > > > > Anyone see any problem with this approach? > > > > The other issue is with all other functions accepting this enum as inpu= t. > > 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 as > > it is in the error path. > [Fiona] The QAT PMD tests for and handles this error. I expect other PMDs > do too. [Arek] - Yes, it is error path but on the other hand we explicitly specify = what value we will return when calling rte_cryptodev_sym_session_init so caller may expect EINVAL when wrong algor= ithm value selected (usually it probably will be ENOTSUP). In this case when setting 3 (LIST_END) on 19.11 app and linking against 20.= 02 (assuming with Chacha) shared build, caller would get success on return = and fully set chacha session, which will probably result in undefined behavior. So shouldn't this function be versioned as well then? Regards, Arek