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 AB463A04BC; Thu, 8 Oct 2020 18:24:25 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2C1AC1B6A3; Thu, 8 Oct 2020 18:24:21 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 77281A69 for ; Thu, 8 Oct 2020 18:24:18 +0200 (CEST) IronPort-SDR: 4XbEBOpgdwBsbAOirPfR1GY0vzzOcmZmp71sTlCRsjQCH1WDK+fFedPH43J0hriZLyjLzDuuL9 JZ0CoaF1YVsQ== X-IronPort-AV: E=McAfee;i="6000,8403,9768"; a="182796257" X-IronPort-AV: E=Sophos;i="5.77,351,1596524400"; d="scan'208";a="182796257" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2020 09:24:16 -0700 IronPort-SDR: /eyLWnLIraj8jR8FqQYIBR5QfnyxYqOXR8nUPc+hzAyMgYIGRscegBSBF2a81ZGmFlHKPotuC6 b62AZSI05wAg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,351,1596524400"; d="scan'208";a="349540826" Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by fmsmga002.fm.intel.com with ESMTP; 08 Oct 2020 09:24:16 -0700 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 8 Oct 2020 09:24:15 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5 via Frontend Transport; Thu, 8 Oct 2020 09:24:15 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.104) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Thu, 8 Oct 2020 09:24:15 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XWaxQFACQaYcNkiJDwEhy4pWJze+koNzu++czPCbAeLnlV1LVR5wWM53B+N36t+KyjgPcobIOYLq04kRO65ASCFoIUaxsNi6tOtil2wiD6qqnrc2fq8L7PX0SobvFDkhOmhpgfZylA/fCh5vnq/sXOe/UL8eQrex016HzO7+sAHJZp8log0CrrZDBEHlOOk3ishPsOsTAPJLRrKGBzlCnCvjk52g3SWryWLZStyuAzlI2gCE/V/h8ZYo+yQ4Of1+HRkHwZvagqZSTFruBIOR/EwO80Avh1EH58kZfdfI/TvPz8iMBHPe8/Owo+Zyz7nMjlof4+y5jTEstY6ENr0LSA== 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=3redCESpDB09/1EahxG4H3NzKzl6lak6Ow5v/SpgF3o=; b=Yk9GdFyaRmvcigiwo5a01TPYN6zMhwip8DCVd5EVCUmsJODj4Ru96AB9kuUzMD0fiXHR/ckx0hQehJv1jHFWC8HWOiU6AJ06d7021U9qo5PcSzzLmSi1oSdNAIQX95Xa7pDusg7uGCFBmeyjleD/tw9bDm90e7cYb+NQw3k/ztw2o+upT/4XoKqJG2wqApifmOIzrnXcfz0mXrOkgPvzyCukz4TmkSfvHKTK5d+JZlst9CZDYxTE1O5PP/096kJHPlnRAJhZMzF9uxW9P3SbljjTwfz2VpQjHWawPPxRAHpSMB8k3cQ3Qsvxv9M4ZmXb3fNCKbYe8mnLjPGCRfCytg== 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=3redCESpDB09/1EahxG4H3NzKzl6lak6Ow5v/SpgF3o=; b=nvZjpfZiwMglwSuPBP9hggZZ27y+g/0hwUNvdaQCFvAxpJVljw4Hunj8IRjDltEs67AZwjoWS+BwwszaXobQ224wF3MkK2IQHzAwfjOuWlxekHX+MS1/SCuVHyTGi4lWuRbNPC7yYX1bcNJdCIslwtqms2BFYozteET/b7tAIMY= Received: from BL0PR11MB3043.namprd11.prod.outlook.com (2603:10b6:208:33::19) by MN2PR11MB4461.namprd11.prod.outlook.com (2603:10b6:208:192::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.22; Thu, 8 Oct 2020 16:24:14 +0000 Received: from BL0PR11MB3043.namprd11.prod.outlook.com ([fe80::11fa:a7fe:329d:9239]) by BL0PR11MB3043.namprd11.prod.outlook.com ([fe80::11fa:a7fe:329d:9239%5]) with mapi id 15.20.3455.023; Thu, 8 Oct 2020 16:24:14 +0000 From: "Zhang, Roy Fan" To: Akhil Goyal , "dev@dpdk.org" CC: "Trahe, Fiona" , "Kusztal, ArkadiuszX" , "Dybkowski, AdamX" , "anoobj@marvell.com" , "Ananyev, Konstantin" , "Bronowski, PiotrX" Thread-Topic: [dpdk-dev v10 2/4] cryptodev: add raw crypto data-path APIs Thread-Index: AQHWkpCfakqJykQoQUaUoLsxzeLwr6mN2MkAgAALuSCAABCrgIAABH2w Date: Thu, 8 Oct 2020 16:24:14 +0000 Message-ID: References: <20200908084253.81022-1-roy.fan.zhang@intel.com> <20200924163417.49983-1-roy.fan.zhang@intel.com> <20200924163417.49983-3-roy.fan.zhang@intel.com> In-Reply-To: Accept-Language: zh-Hans-HK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.5.1.3 dlp-reaction: no-action dlp-product: dlpe-windows authentication-results: nxp.com; dkim=none (message not signed) header.d=none;nxp.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [95.44.220.85] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6fff7090-a648-4c30-b5c4-08d86ba698e0 x-ms-traffictypediagnostic: MN2PR11MB4461: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: m9B2OBttDb6SfY+cKMFsyTBErsy19c23LgL50Qwqm+dmcj1x3NVC85p9hsi8gTy6GElSm7or7Sn82FmumEbWbKKZNrBnE7PHHRuhYhWCGO0hMdkRlSu6KKKe6eGTGLvwEEVx6v1k3r6lGVfzutyBFPplN6PrSwUIuiTdbxhzWrrZjq5aKFR4TTY/31EuQK10GIDpFAGpJAPKSKNzAN06Pwg6H1cFjJTaWxK81qvmFkecr7hcIPG2A5ElgvW/xFOkKyV1carNH6f+1+nEBqrJsU1ZD1Yhp2gpXE82c8tf2Nmg49Nijq7bYnp3T/A+9YvZ9VoOvo9buUHlKmr6a1AS/g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3043.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(346002)(136003)(376002)(366004)(396003)(33656002)(478600001)(107886003)(76116006)(66446008)(66476007)(8936002)(66946007)(66556008)(55016002)(64756008)(5660300002)(9686003)(316002)(110136005)(54906003)(71200400001)(26005)(53546011)(6506007)(2906002)(83380400001)(4326008)(8676002)(86362001)(52536014)(186003)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: /omQVLYBGp7//tWjiBAUpUd8b1+nyHxIm4IwkhaJ4EILf3CsNbl+zidualzkPqsm60AEJ6Zd+9H2cpoeHs23CpGj77cQ0YW+XKM5H4BYvZBEmDgVLy5jcbvWEOXV05Db9lZOOZGp3IMcw70BHfHE87EXNfFGkLlneEcdI822rrQCVN2Rr0uRRFn6BKQ5c3AqHk9x+rNPUdHpujhUn9W2XyDwFsXRkyebPpb/KlTOclYQ2M+CMBjcg5OBSvtHokNzR6K/HfMdr2CK8vpFJNwwwcYGLUMpvtPlQGx2lvlzBP61VdeOOaoGL2xCZwtbwDaE6d/mF6YVXkhXojCeMZULYoxtzuYJ60k3QRe9qQwIWt9d0ajaaJRD6ls85LmlyIdbRTJ6gBdLz/j45sFXgIl4qs7jl7MssFjIV4PVJ/XFLMQ+fttUaTG+R21jtTVDT8m+l7nQczcHbL0yyTUrVNq8kvWPAE4cs1E69881ZN93latFCtmd/3qjyYCfNfv8ULxQdhEPQt9mBiaIK7znJ/nuJHRDAjWLtzZHUvJNwPBbzBss3Mcr2bpzuQ2NHEyvrOi13bpfmqr4h+qoWyum3Wm0PVZPr5IfZWuZibb2dEh5u2EbP6LjKMDJ73DS6ex2TDsR4Nn2CvloooKhDsnhRiywxg== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3043.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6fff7090-a648-4c30-b5c4-08d86ba698e0 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2020 16:24:14.3213 (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: EHYdIHmNPRylR0+5Ho9PYQNP7pQPPXK3ypP886Si1RLxFeT11fS3L1yTNDQP16itBoTDN7Bn9XbZxbaAhpt1sw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4461 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [dpdk-dev v10 2/4] cryptodev: add raw crypto data-path APIs 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, Good idea. Will do. > -----Original Message----- > From: Akhil Goyal > Sent: Thursday, October 8, 2020 5:08 PM > To: Zhang, Roy Fan ; dev@dpdk.org > Cc: Trahe, Fiona ; Kusztal, ArkadiuszX > ; Dybkowski, AdamX > ; anoobj@marvell.com; Ananyev, Konstantin > ; Bronowski, PiotrX > > Subject: RE: [dpdk-dev v10 2/4] cryptodev: add raw crypto data-path APIs >=20 > > > > +During the enqueue, the cryptodev driver only sets the enqueued > > > descriptors > > > > +into the device queue but not initiates the device to start proces= sing > them. > > > > +The temporary queue pair data changes in relation to the enqueued > > > descriptors > > > > +may be recorded in the ``struct rte_crypto_raw_dp_ctx`` buffer as = the > > > > reference > > > > +to the next enqueue function call. When > > > ``rte_cryptodev_raw_enqueue_done`` > > > > is > > > > +called, the driver will initiate the processing of all enqueued > descriptors > > > and > > > > +merge the temporary queue pair data changes into the driver's priv= ate > > > queue > > > > +pair data. Calling ``rte_cryptodev_raw_configure_dp_context`` twic= e > > > without > > > > +``rte_cryptodev_dp_enqueue_done`` call in between will invalidate > the > > > > temporary > > > > +data stored in ``struct rte_crypto_raw_dp_ctx`` buffer. This featu= re is > > > useful > > > > +when the user wants to abandon partially enqueued data for a faile= d > > > enqueue > > > > +burst operation and try enqueuing in a whole later. > > > > > > This feature may not be supported by all the HW PMDs, Can there be a > way > > > to bypass > > > this done API? > > > > We can add another feature flag > > "RTE_CRYPTODEV_FF_SYM_HW_RAW_DP_ALLOW_CACHE". The PMDs > who > > do not support this feature can simply return "- ENOTSUP" when calling > > enqueue_done and dequeue_done function. What do you think? >=20 > Can the enqueue/dequeue API return a flag which decide whether > to call done API or not? > Returning ENOTSUP will break the execution. >=20 >=20 > > > > +int > > > > +rte_cryptodev_raw_configure_dp_context(uint8_t dev_id, uint16_t > > > qp_id, > > > > + struct rte_crypto_raw_dp_ctx *ctx) > > > > > > rte_cryptodev_configure_raw_dp_ctx > > > > > > > +{ > > > > + struct rte_cryptodev *dev; > > > > + union rte_cryptodev_session_ctx sess_ctx =3D {NULL}; > > > > + > > > > + if (!rte_cryptodev_get_qp_status(dev_id, qp_id)) > > > > + return -EINVAL; > > > > + > > > > + dev =3D rte_cryptodev_pmd_get_dev(dev_id); > > > > + if (!(dev->feature_flags & RTE_CRYPTODEV_FF_SYM_HW_RAW_DP) > > > > + || dev->dev_ops->configure_dp_ctx =3D=3D NULL) > > > > + return -ENOTSUP; > > > > + > > > > + return (*dev->dev_ops->configure_dp_ctx)(dev, qp_id, > > > > + RTE_CRYPTO_OP_WITH_SESSION, sess_ctx, ctx); > > > > +} > > > > + > > > > +int > > > > +rte_cryptodev_raw_attach_session(uint8_t dev_id, uint16_t qp_id, > > > > + struct rte_crypto_raw_dp_ctx *ctx, > > > > + enum rte_crypto_op_sess_type sess_type, > > > > + union rte_cryptodev_session_ctx session_ctx) > > > > +{ > > > > + struct rte_cryptodev *dev; > > > > + > > > > + if (!rte_cryptodev_get_qp_status(dev_id, qp_id)) > > > > + return -EINVAL; > > > > + > > > > + dev =3D rte_cryptodev_pmd_get_dev(dev_id); > > > > + if (!(dev->feature_flags & RTE_CRYPTODEV_FF_SYM_HW_RAW_DP) > > > > + || dev->dev_ops->configure_dp_ctx =3D=3D NULL) > > > > + return -ENOTSUP; > > > > + return (*dev->dev_ops->configure_dp_ctx)(dev, qp_id, sess_type, > > > > + session_ctx, ctx); > > > > > > What is the difference between > rte_cryptodev_raw_configure_dp_context > > > and > > > rte_cryptodev_raw_attach_session? > > > And if at all it is needed, then it should be > > > rte_cryptodev_attach_raw_dp_session. > > > IMO attach is not needed, I am not clear about it. > > > > > > You are calling the same dev_ops for both - one with explicit session= time > > > and other > > > From an argument. > > > > rte_cryptodev_raw_configure_dp_context creates a shadow copy of the > queue > > pair data with in ctx, where rte_cryptodev_raw_attach_session sets the > function > > handler based on the session data. Using of the same PMD callback > function is > > to > > save one function pointer stored in the dev_ops. If you don't like it I= can > create > > 2 callback functions no problem. >=20 > I don't like the idea of having 2 APIs. >=20 > Why do you need to create a shadow copy of the queue data? Why it can't > be > Done in the attach API by the driver? In v9 it was doing that, why is it = changed? >=20