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 99014A0566; Tue, 17 Mar 2020 20:10:48 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8D6BB1C0B8; Tue, 17 Mar 2020 20:10:47 +0100 (CET) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 8AD2E1C0B7 for ; Tue, 17 Mar 2020 20:10:45 +0100 (CET) IronPort-SDR: 8mQSlLRQ9VTier2aWJ1lYX2SbthUnYBzfLkTzTTcholqOqV2SyWlds/u5R98OGza4jJi6zG7ur ogLvhgaxXBVQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Mar 2020 12:10:44 -0700 IronPort-SDR: OPO+s8tDMhNBU1CIqVCQMQ/ZuVJqii//SNYw96JJhWARSWz7yaAQ2TNWhWjcAfjOVB9u/IYk/B 2UmiPJaoSIfg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,565,1574150400"; d="scan'208";a="443865655" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by fmsmga005.fm.intel.com with ESMTP; 17 Mar 2020 12:10:43 -0700 Received: from orsmsx157.amr.corp.intel.com (10.22.240.23) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 17 Mar 2020 12:10:43 -0700 Received: from ORSEDG001.ED.cps.intel.com (10.7.248.4) by ORSMSX157.amr.corp.intel.com (10.22.240.23) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 17 Mar 2020 12:10:42 -0700 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.169) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 17 Mar 2020 12:10:42 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IMsirwggH7TUwr2solgJBjS6a8m3LGm8u19h5oPtBmsC+F6aExjmcQ8rjysNz5rMZI7NmvnZzSJpojuAcstM5zUWAEc/maFgAzQpvd167BTciVuiJzza/u9dUxQjVnixIbKvZQuCsEdGJFVPLf2o5oDYpryO30X5xIT4wFpzgFIjKJag/uhOaxb0tidCjLeFEMc7Shq6ZrnvZ3AhkVVgw5nTOcuKviTipnB6dI0f1UMXSRoNHUALjDdH83ZIe9eA6nr7WRCl/6J1lw0j9nhogakzUrfd1+1jJoE1iiJbW6m1op3uPx++Enr6emr8SnK1aCGzC04Vv9zbxwuPvjkGTA== 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=ZRqN5f2PTJkLm4uaTv8XrQZZsWwD4uobPF0V9ZNRjFo=; b=D65jdhmElQ86FAXIK0RhfOJk0ArmQTEQc3wtJktGCNvPePnwHY3ytFuvWT35i8YhECVUs+5rayxWm05CtQL+xL/uvruNaGie14F2em1CTZQJs20L2GWMUQ5BNTDwmeBsIMlZV5+hX4pdHDfKAeVU4Y5mw4vJpU1w9XQKpw52ggN8MxNgKRZ5kWH2gB/C2gVzpTw25O6VqFbFJigfJqpdLpmEMk6umH/pWBUlEh6SlXSn2Lo/7IkwE5mZC2PCWMIsBOPhU2EcziQhUIAcxpHLtHeOB8FhoLXXT2S4Wq6PZgHdNTTdDWojHGbuZZbPh1lM7JvsYg6JbyGGyzI60JZCUg== 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=ZRqN5f2PTJkLm4uaTv8XrQZZsWwD4uobPF0V9ZNRjFo=; b=g4W8lyETmS3yy85rRiB3OwPcEsez4jbqsURIYrJaNprDKaOiKdc47jXK/W5bWjnljA34iqbYLbj4gKpRiL/iLDs7ebOsYGzXohJtm/qZWkbbYvML6RIfLpgJiYvU4Ictst8wJVV3zrbiQbX3PU0TwpKNzwz9Me4ULIq8PbrMaEw= Received: from BL0PR11MB3316.namprd11.prod.outlook.com (2603:10b6:208:68::28) by BL0PR11MB3188.namprd11.prod.outlook.com (2603:10b6:208:61::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13; Tue, 17 Mar 2020 19:10:40 +0000 Received: from BL0PR11MB3316.namprd11.prod.outlook.com ([fe80::e9eb:fb8f:f54e:4622]) by BL0PR11MB3316.namprd11.prod.outlook.com ([fe80::e9eb:fb8f:f54e:4622%6]) with mapi id 15.20.2814.021; Tue, 17 Mar 2020 19:10:40 +0000 From: "Kusztal, ArkadiuszX" To: Thomas Monjalon , "Trahe, Fiona" 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: AQHV1sl6v2NXnfoHmkOb0gtPonzveKgB6XuAgAAHogCAAB+GAIAAAuCAgAFOQQCAAEVxAIABLWUAgAMQ1QCAABrKgIABOz4AgACAVgCAAAb/gIAAFsaAgAAktQCAAN6iAIAAJxkAgAA0qgCAAAHrAIAAHfYAgA3YuCCAMkX4gIAAA1cAgAGPDDCAACUlAIAANdJw Date: Tue, 17 Mar 2020 19:10:40 +0000 Message-ID: References: <20191220152058.10739-1-david.marchand@redhat.com> <2810256.WAvfycf1tz@xps> <56588879.matp6XCIr4@xps> In-Reply-To: <56588879.matp6XCIr4@xps> 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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNDUzOTg3ZmItZmNhZi00N2IwLWJiOGQtODAxNTZlNTVlMmNiIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiSDZ3bGVIcVJQc0FjVDRYazNIbWYwdnFqVmY5cVwvaHQwNzFJSG1YdHYyRFk2TjFVSFM3U3E5UmVIYUR4bHBWZHcifQ== authentication-results: spf=none (sender IP is ) smtp.mailfrom=arkadiuszx.kusztal@intel.com; x-originating-ip: [134.191.227.39] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5033e251-9330-4acc-5e0b-08d7caa6e266 x-ms-traffictypediagnostic: BL0PR11MB3188: 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: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(199004)(6506007)(8676002)(52536014)(26005)(7696005)(55016002)(76116006)(5660300002)(66476007)(66556008)(6636002)(66946007)(66446008)(64756008)(33656002)(81156014)(71200400001)(186003)(2906002)(81166006)(53546011)(54906003)(8936002)(86362001)(4326008)(107886003)(7416002)(9686003)(110136005)(498600001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR11MB3188; H:BL0PR11MB3316.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: gGe0wKgMN02stZQOZ+EEfp6oYSMnmsHiL8l33096TzdG313tl4bCg52rC9KFOGk3QmK5JF9vEkwJjqFREY8YpRoCFkvXBcCXQ160JYngtV+uvinnceOA3fr5/lPQmJQyNn/EYBdzjT/egw4b0Okcz0kMxF/viCuevhL058ePKb7FkmJrOU5Ovq9xadDi+aYxel5yQZkNvTns6roEOXJdmOpM7+85BpAbnNUsbesdG/H3rySyGZRqhMqPqMdPbYG1kOu3mquVfA0ceiOLMw1953DkoQt5F2laZoB2E8o2CO4xtwq+mazkjLaJjMb/9QhsaUBAbqn2T/TiP6Mlthv2b5W+pOlfAW8murWZUp5xiSuh4ipBHjp/XyiCR+ZR6mbvQGHCPp8rMmF6EKxJPxafEzLwQyvBM8FoYLdRuKkuKdb2mtKXr3pXZmUZmNCJEQWl x-ms-exchange-antispam-messagedata: BfXYuwouFlgnrYzd6yd7cWcn5MMA/NnWhXxLCFLNQbit8ONgHP7yTPaTjQzMyF/Mhm+6Wnvow9VWH+0pprh0djgw43v5RpIhUT6P8jhsB6jWGygN+QoNUXeVpFjckuV7CAG0kIUJbCLvpq5yOKpczQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5033e251-9330-4acc-5e0b-08d7caa6e266 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2020 19:10:40.6416 (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: QTHU/tfNp+XxFAIrJ12YBv/PKo/PAaK29STsRLfFSj+affWly8j4XY0EowI2t07FVlWc4LxuQ5uTo1UgmbbDB8vrY6LD/3XYcNlsQjW5FeE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3188 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" > -----Original Message----- > From: Thomas Monjalon > Sent: Tuesday, March 17, 2020 4:10 PM > To: Trahe, Fiona ; Kusztal, ArkadiuszX > > 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 > Subject: Re: [dpdk-dev] [PATCH v2 4/4] add ABI checks >=20 > 17/03/2020 14:27, Kusztal, ArkadiuszX: > > Hi Thomas, > > > > > -----Original Message----- > > > From: Thomas Monjalon > > > Sent: Monday, March 16, 2020 2:09 PM > > > To: Trahe, Fiona > > > Cc: Kusztal, ArkadiuszX ; 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 > > > > > > Subject: Re: [dpdk-dev] [PATCH v2 4/4] add ABI checks > > > > > > 16/03/2020 13:57, Trahe, Fiona: > > > > From: Kusztal, ArkadiuszX > > > > > > > > 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 trimmed > > > > > > 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 operate 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 capabilities with/without ChaChaPoly depending on the appl > > > > version. To resolve this, within the rte_cryptodev layer, we > > > > propose to 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 > > > malloced by the lib. > > > > > > What happens if the capability is removed from the original > > > capabilities input? > > > > > > > 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 END element (which can be done without malloc) in this > > > > corner case of > > > a corner case. > > > > Anyone see any issue with this? > > > > > > How can we use the feature if it is not advertised in capabilities? > > What Fiona meant is that empty capability would indicate error conditio= n in > this case. That's why she asked if you ok with this API breakage. >=20 > Sorry I'm lost. > Please could you show what would be the usage? >=20 So this case looks more or less like that: There are two versions of `rte_cryptodev_info_get` rte_cryptodev_info_get_v20 (versioned) rte_cryptodev_info_get_v2005 (new default symbol) Default version works normally as it will be called only by app build with = 20.05 version. When prior to 20.05 app calls `rte_cryptodev_info_get` version v20 is calle= d. This function will remove Chacha Poly from capabilities, but to achieve = this we need to get some memory to store `new` set of capabilities per devi= ce (without Chacha). So: new_capability[dev_id] =3D malloc( (num_of_capabilies - 1 (chacha)) * sizeo= f(struct rte_cryptodev_capabilities)) The small problem is how to handle malloc error: If (new_capability[dev_id] =3D=3D NULL) { /* What to do now as rte_cryptodev_info_get is void function, and API does= not say anything about error condition */ /*So Fiona suggestion above is to inform user of an error by doing this: */ dev_info->capabilities =3D cryptodev_undefined_capabilities; /* Where=20 static const struct rte_cryptodev_capabilities cryptodev_undefined_capabili= ties[] =3D { RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST() }; */ } Sizeof rte_cryptodev_capabilities is 38 bytes, padded to 40. So properly co= nstructed capabilities can take at most 1920 bytes. No system should ever = fail doing that though iam not an expert. Other option could probably be to= preallocate this memory. This is how I understand that. Another question is can something like that be done if API comments of `rte= _cryptodev_info_get` function does not say anything about any potential err= or? Regards, Arek