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 619A2A046B for ; Fri, 28 Jun 2019 18:11:07 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C163437B4; Fri, 28 Jun 2019 18:11:05 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id A6D1A34F0 for ; Fri, 28 Jun 2019 18:11:03 +0200 (CEST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x5SG3vC7029594; Fri, 28 Jun 2019 09:11:02 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pfpt0818; bh=8hyitVcl/zKsi8nQxpCUUfajRHzRhoJj8YHVNZ2OZy8=; b=OD38cv3fRX9Z3rS8DM98w4hzncEtnuf+e95SthRPiMqTakDY6Q6/8XK3VvnnaMhRluC1 fBu7yB/Lzbw6CnXiO9BDHIrrGjhEDZYsRrNnPeHFzakctY89EDa+ymAaqF4rxF8wU+gl XuDp8/y7jdorjPNzb37T+WQowzRi2lH56j6EzFPvUtzdjufCBqeZv3BpqYgvVN2c3pG8 PU/M/It3edXQty8TWyqRcY+9DqfHMJhKB701cJZNgb1Hx98k92md/2a6jDoO/5u/b456 1pwXoj3xmLl6zpX+KRu6oDHfmiv0BYSUc4jwJvIVUzz34DCaASMfISdOrgLZyHpmAYRP tA== Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0b-0016f401.pphosted.com with ESMTP id 2tdkg18ku9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 28 Jun 2019 09:11:02 -0700 Received: from SC-EXCH04.marvell.com (10.93.176.84) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 28 Jun 2019 09:11:00 -0700 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (104.47.49.52) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Fri, 28 Jun 2019 09:11:00 -0700 ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=TB7Tjy56xCF74t/a2xE4MIS8Omw/qWWn//Oy2TROgjM1GKLwzY33uf/QIc2lyjsvI1V1kubsAnoTsrhSEze0cIJYBNNZoQCTdvIKFvwKipgZ0egAwTbBzIh18fHbpUysJ/O0cHzUKNDaaTIXYsqpy+5vj4ybmdunnzqsBHn+Ua8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8hyitVcl/zKsi8nQxpCUUfajRHzRhoJj8YHVNZ2OZy8=; b=GHAqtb/EtGW445B1N3JdnkmaTl+tpXCgQCc0B3Ui9ZTgijuhtG8tmzD9fhXUNj0aXkpAJSSX0Aar282CxXly1kCvNeYCAp/q0nMgKYl9dF6ghmFecGHqiLDO8LhTe7Y6rtVr/YKkqkDqPR8GY0d8ZRHKYDRDXqT6unBQ1vXDiVU= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8hyitVcl/zKsi8nQxpCUUfajRHzRhoJj8YHVNZ2OZy8=; b=w4lzwDiUtsI+lK3QEkU1QOl3cfgoWmX3qAXsvM8gMUB+cx7gQqHqulKt9sfBcsL4MWRy41ZUXxUajJAiyrrGDrydvnpEORw9dOhWUY4ZXq6eub6V0n3nA5CHKNkYgqytiLKbvCDfANMg+MnDZQw4DOAk0QaMAuRSE1bVH7/NBtg= Received: from BN6PR1801MB2052.namprd18.prod.outlook.com (10.161.157.11) by BN6PR1801MB1988.namprd18.prod.outlook.com (10.161.155.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Fri, 28 Jun 2019 16:10:57 +0000 Received: from BN6PR1801MB2052.namprd18.prod.outlook.com ([fe80::e15e:f648:497:ea77]) by BN6PR1801MB2052.namprd18.prod.outlook.com ([fe80::e15e:f648:497:ea77%7]) with mapi id 15.20.2008.018; Fri, 28 Jun 2019 16:10:57 +0000 From: Shally Verma To: "Trahe, Fiona" , Akhil Goyal , "Kusztal, ArkadiuszX" , "dev@dpdk.org" Thread-Topic: [PATCH] cryptodev: extend api of asymmetric crypto by sessionless Thread-Index: AQHVKD07D5Y9TE/TGU6fyYBZ3yyQM6aqZdAAgAUH9wCAAdOy8A== Date: Fri, 28 Jun 2019 16:10:57 +0000 Message-ID: References: <20190603194411.8352-1-arkadiuszx.kusztal@intel.com> <348A99DA5F5B7549AA880327E580B435897A26ED@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B435897A28B6@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B435897A68FE@IRSMSX101.ger.corp.intel.com> In-Reply-To: <348A99DA5F5B7549AA880327E580B435897A68FE@IRSMSX101.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.49.225.231] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0d112f64-0e82-4673-5556-08d6fbe3346c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN6PR1801MB1988; x-ms-traffictypediagnostic: BN6PR1801MB1988: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00826B6158 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(376002)(136003)(396003)(346002)(13464003)(189003)(199004)(14454004)(81166006)(6436002)(305945005)(2501003)(476003)(99286004)(6246003)(25786009)(74316002)(26005)(33656002)(186003)(86362001)(2906002)(6116002)(11346002)(3846002)(478600001)(110136005)(102836004)(71200400001)(14444005)(486006)(316002)(8676002)(55236004)(66066001)(71190400001)(9686003)(81156014)(8936002)(256004)(53936002)(446003)(76116006)(66446008)(73956011)(66946007)(5660300002)(64756008)(66556008)(76176011)(66476007)(55016002)(68736007)(229853002)(7696005)(53546011)(6506007)(7736002)(52536014); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1801MB1988; H:BN6PR1801MB2052.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: marvell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: eg+deecT4R2UeOMii4kBiRrouK8aZVIZYkY/+UoTNY5d/HTe+sGsJsUaRiqEkRgtzn79UEcRjdsKsKGUII20/ppPrDUhmDnoFBnMAjGW2FpQS+tHvNCRjfCTHFUGaerdqmu7O5Y02x0SXb5VwaWXyj1djazyW30d1M2G2UgOFsDACm7s8qAyAoMmKbAvN0sTf7kwSG95pxNC8gvmRylxmNKzJBimu6LExIc/8f/VoUtQFqkzvYVXBPBALmrgCWQ5tI16jy6Yd4DufrShGqKwpwqjCMIl/h8jrK9rLQ2nRR+qh6/2Y0lmVo5nJr+A2z3YykAggAvQ2wdUwfdaFdCQ/0PKpuTXjFslgF3oeq0vtAC+1jzQ8+LSNjXepTd364bvIOfQXZLu/0k5n88oh2K0vMT35KekxLamDRRWiDoc//g= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0d112f64-0e82-4673-5556-08d6fbe3346c X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2019 16:10:57.3387 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: shallyv@marvell.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1801MB1988 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-28_07:, , signatures=0 Subject: Re: [dpdk-dev] [PATCH] cryptodev: extend api of asymmetric crypto by sessionless 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 Finoa, Akhil > -----Original Message----- > From: Trahe, Fiona > Sent: Thursday, June 27, 2019 5:25 PM > To: Akhil Goyal ; Kusztal, ArkadiuszX > ; dev@dpdk.org; Shally Verma > > Cc: Trahe, Fiona > Subject: [EXT] RE: [PATCH] cryptodev: extend api of asymmetric crypto by > sessionless >=20 > External Email >=20 > ---------------------------------------------------------------------- ... > > > > > So I propose adding 2 feature flags to the API > > > > > RTE_CRYPTODEV_FF_ASYM_WTH_SESSION > > > > > RTE_CRYPTODEV_FF_ASYM_SESSIONLESS and including in this patch > > > > > the PMD and UT changes to set and test the first > > > flag. > > > [Fiona] symmetric crypto is inherently session-based, so all PMDs > > > support this. I don't know how much real use SESSIONLESS actually get= s. > > > For asymmetric, my understanding is that sessionless is more likely t= o be > used. > > > Sequences of ops using the same params/keys are an unlikely > > > use-case, so there's no advantage to setting up a session and it's > > > an extra API call so preferable to avoid. > > > > Agreed, if Asymmetric is not likely to have sessions, it should not cal= l that > API. [Shally] I would rather say, asymmetric are using session based calls but t= hose are not so useful as unlike symmetric, session params doesn't say same= for larger amount of data. So, its instead useful to have sessionless support for same. > > > > > That said, I think it would be ok with one feature flag. > > > If a PMD doesn't support WITH_SESSION, the session_init API will > > > fail with - ENOTSUP, so giving the app the information it needs. > > > This can be documented as a PMD limitation and I'm ok with it not hav= ing > a feature flag. > > > However if a PMD doesn't support SESSIONLESS, then the fail will > > > only occur on the op_enqueue_burst. > > > > Yes on the first enqueue, before actually submitting to the hardware, > > in the driver itself Before sending the request to hardware and return > OP_INVALID_SESSION. > > > > > Failure to enqueue the next op is a typical outcome on a busy > > > hardware device, and the app will likely assume the device is busy an= d try > again with same result. > > > > The PMD will not be sending the request to hardware if sessionless is n= ot > supported. > > And app will not enqueue the op again if the previous error is > OP_INVALID_SESSION. > > > > > The PMD could change the op.status to OP_STATUS_ERROR or > > > OP_INVALID_SESSION but it would still require the app to check the > > > status of the next op which failed to enqueue. I think it better to > > > detect this before the op_enqueue by providing a > > > RTE_CRYPTODEV_FF_ASYM_SESSIONLESS feature flag. > > > > On second thought, we can have another value in the enum(op->status) > > to say sessionless Is not supported if OP_INVALID_SESSION looks > > ambiguous instead of setting a feature flag and making each driver set = it if it > support sessionless or not. > > > > I believe that would be simple and will not bother the data path or the= busy > hardware. > > Anyways in case of sessions also in sym, we make session on arrival of > > 1st packet. That same logic Can be applied here also. I don't think tha= t will > be an issue. > [Fiona] The issue for me isn't that OP_INVALID_SESSION is ambiguous - > although that's also true - it's that if an op fails on the enqueue, appl= ications > may not check the op.status and so not notice the fail and would likely > resubmit, assuming the op didn't enqueue because of a busy device. > This could result in an infinite loop. >=20 > Also in my understanding the enqueue_burst() call is part of the data pat= h, in > which I'd include the PMD processing as well as the hardware processing, = so I > think adding a check for this case DOES affect the data-path. > But a few extra cycles on the data-path to check the op.status is not a b= ig > performance impact for asymmetric crypto. > So I'd suggest adding a generic RTE_CRYPTO_OP_STATUS_NOT_SUPPORTED > and using for this case as long as we also document the following on the = API: >=20 > For asymmetric crypto operations, if an op fails to enqueue, the op.statu= s > must be set appropriately and the PMD should return without enqueuing > any subsequent ops in that burst. > It's up to the application to check if less than the full burst is enqueu= ed and in > this case to check the status of the first unenqueued op. If still > NOT_PROCESSED, it's likely due to a busy device and a later retry with th= e > same op can be expected to succeed, for any other error the application > should not resubmit the same op unless the error has been rectified. >=20 [Shally] I would favor to have feature flag instead, to keep it simple.=20 We're relying too much on documentation here. Any op status, be it INVALID_= OP_SESSION, or NOT_SUPPORTED does not give clear reason for failure. Assuming we agree on feature flag, then next ques= tion comes if PMD set SESSIONLESS feature flag, then does that mean it supp= ort *only* sessionless OR both "session" and "sessionless" ? To solve this, we can define it like this: 1. if PMD does not set _SESSIONLESS feature flag, that implicitly mean it s= upport session based only (which is current case) 2. if PMD does set _SESSIONLESS feature flag, then app can certainly use se= ssionless, but if it invokes session init API, then - if PMD don't have session support, it should return NOT_SUPPORTED in se= ssion_init() - if PMD do have session support (which will be our case), then it will a= llow session APIs. Then its app discretion to choose either of these Does this sounds okay? Thanks Shally > Note - it's out of the scope of this thread whether the same should be tr= ue > for symmetric crypto ops. > > > > > > > > > > > > > We'll follow up with SESSIONLESS QAT implementation and UTs in a > > > > > separate patchset. > > > > > Also documentation updates should go with this API patch, i.e. > > > > > - update section 16.7.2 in the cryptodev programmers guide - > > > > > and review > > > that > > > > > doc in case other sections need updating. > > > > Yes this needs to be updated if the implementation is complete and > > > > we have > > > some PMD supporting > > > > that. > > > [Fiona] Are you saying we need to submit the PMD changes with this AP= I > patch? > > > Or can we do > > > separately as we'd planned? > > > > I believe you should update the documentation when some PMD support > sessionless. > > I think we should hold back this patch, until you have a sample PMD/app > ready for reference. > > > > You may end up adding a few more updates to the lib while actually > supporting the functionality. > [Fiona] ok >=20 > > > > > > > > > > > > > > - fix comment in rte_crypto.h under STATUS_INVALID_SESSION > > > > > - release note > > > > > > > > > > > > > > > > > > > > > > -Akhil