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 B049DA04BC; Thu, 8 Oct 2020 18:07:49 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 804EC1B9E0; Thu, 8 Oct 2020 18:07:48 +0200 (CEST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40081.outbound.protection.outlook.com [40.107.4.81]) by dpdk.org (Postfix) with ESMTP id E8A781B96B for ; Thu, 8 Oct 2020 18:07:45 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NtG0SJnoB7U/AnVVJl/oSoDNUMEi65A4dscXbG1IXIPX/KeBrC3JXYVICqkEYIVlMiI3CJ6i10265ovhe9zmypbst6m0RpAeVnI5/wZXNFH75gsBx0klU4zhtAqH1LcLSOQQru0Gk8t2JSODJsftw6hHomFrY8VsfEGmC4MX7VyVNwavcAJ28bRRwSgYbLsBHNZY8BPGJeX/znQbcxs9yqrry/bZxYrJDEGqpWCuFE9eZ8gzctYTo8iyv6ENP/QQ3qLRW3cG36ErjuufpMV4CgPB2cP7dAU5RlZpkVJ/0XgPyT26nXYGfyFGveXqtQUgRWxRsanQFOydoPAXH3OD4A== 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=3QwlZk0wYy1yQnXVa9oXmBhGee/8Z4rRmPD1P6HxOh8=; b=RiM+phYJ9QNCXeQQKTvqPgXKaWhhPwzLmZDIar5GLE57x57otjTVaddflMy+z5z5VFhokLTyP50FEXqnphE0NGK9aIcya2bp2BTi6iKJtfdkr4tcLsC/Syi8lx0TbbgaP99ozaD39e8iS20OTEwBzMMhLHtPssWWxGGlgT//n/THpgWeNoNPyMxNz6gZFlVNwLr7RTI/OlO+Gk5RFSa6Q+F2pTfSG/0zfD1VLrsd5Ey63rIbA+rkreEl+0MekxaFzxVxJGXt5jHuPddWOrP7vykb7WQS27G8VNWY1P9W80O5DlyXOZwRJqPN1ofjPO1QUgubTRPUf14rOfsTZLajCg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3QwlZk0wYy1yQnXVa9oXmBhGee/8Z4rRmPD1P6HxOh8=; b=QNO2bN8I7fRJ+4x3/81rWOozrVei74q++E/AXv/fe3Qm0m2GgZISpfZ0izLQC+P29x1C+cP4j+GCzA1zgcGlpblBi4KVO1dH2V+PA3ZRFqBUXHBqfsLXQt1OrtcVAWMNBikkYxPQeDK5L0SisbewfcDG6iVKUfG+lmzzo5l7NYk= Received: from VI1PR04MB3168.eurprd04.prod.outlook.com (2603:10a6:802:6::10) by VI1PR04MB4334.eurprd04.prod.outlook.com (2603:10a6:803:3e::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.34; Thu, 8 Oct 2020 16:07:43 +0000 Received: from VI1PR04MB3168.eurprd04.prod.outlook.com ([fe80::9513:3b55:931f:216e]) by VI1PR04MB3168.eurprd04.prod.outlook.com ([fe80::9513:3b55:931f:216e%4]) with mapi id 15.20.3433.045; Thu, 8 Oct 2020 16:07:43 +0000 From: Akhil Goyal To: "Zhang, Roy Fan" , "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: AQHWkpCTO1BRq1qbhkKXgZJDe+ouAamNxjPggAAkNwCAAAhNsA== Date: Thu, 8 Oct 2020 16:07:43 +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: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=nxp.com; x-originating-ip: [122.180.231.103] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 2d0f9b5c-3ee6-4551-647a-08d86ba44a04 x-ms-traffictypediagnostic: VI1PR04MB4334: 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: XqID2xvnCDFmadBtQJUTFDLwS1JCXfUtJdlhS8rX0Ok9bQ7ZQSWzzV2Aimz0FmIb6v4CTzEksaYGmLI3IrWMEK/hfqkylD1pwUkREKe14UkgOvUV3i3XmSqCJP0rvF0IYScB/p1768jwF0I0W6yS+8dxQQL56T5/fxZTPyzhWAQiv96XQWgegi6519QVlAEruj7K/+xeCECe6hnr3BSKbi0kHd/oHzXscmVQrkgLoeW2HiHTqn5NOgx94WK2gZHkycriPrh1YYPF96HlOb/tgzL+KFQ15KPe7dv8ckL2V3kqLDHr6Kb0tsuIAOLNrGLSY4x/BS6WKu7Vh76xjWUlCw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB3168.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(346002)(376002)(39850400004)(136003)(9686003)(54906003)(55016002)(33656002)(2906002)(4326008)(8676002)(110136005)(83380400001)(86362001)(316002)(26005)(52536014)(44832011)(66556008)(5660300002)(7696005)(6506007)(64756008)(478600001)(186003)(8936002)(66946007)(66476007)(66446008)(76116006)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ZnIob7hVOL8x9HVBNeM5R4FUwBQrqsLMCSfihasq3li2aqHDbDKHONf5VNTTUGcjPff4sxNYrvy5xl3/L/F2Va3N5fzSlZVYkzUQJIqY86PtiZtHGFgLyAQHwvCn3bw1WfFK6qkfEOuiyGKfQcwsBGdSt+VwrvmS/mMiUIcGsl7gPdRhpXaRxK7dl+XuFVjQakxm61pMO+rGDmmA1qN3x4EVo7K0P9Cnk3vH1yLx3Ds5ezxxlgps/OXwkkb0TRW/COrtW3/qCt/UpC2OPTMTISAdq8RnsjpkY60OghekprPqSoIT7sS6SlIuVxPtJFKEKYtGsZMiEZdjoVKK9yXVlcYgDBkzV9mgT4ZatLywbvRQ2QaK0HOaYCcqpPOZ16hHr2EWKVcm0hij81lDeXa/qKOmKxtXHsW6wJZjoQaOHpW+W/VG2yFIk20JvtyKDr//L7KNRllY6tpiGdcGVNIMprFaEi1LH8jCW+WeJOwjUhnZjkssjZafvZ9iiCGnj7DbxADsHzVQ/Mfmgdcz1JnFkGmYgaYEjfm3/z6EMdHtN/l33c2cLIKlXh6hRtwBEnsf/UrxIJ+oLofhpjN0+wMVfz8LLVKWL7SsrZcwmXPdO4nRNmObEOiBTSAj8nYwcIZmh+SWryGJH1yKJAWXkXgSRA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB3168.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2d0f9b5c-3ee6-4551-647a-08d86ba44a04 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2020 16:07:43.3205 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rnXmHziId5OLYBJd3sh3hcacb3J9SqOQrMS/628SLnooZNCATX58hbfAEyyJo8JqsbcJWQDP47cksJi2l/i1VQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB4334 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" > > > +During the enqueue, the cryptodev driver only sets the enqueued > > descriptors > > > +into the device queue but not initiates the device to start processi= ng 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 th= e > > > reference > > > +to the next enqueue function call. When > > ``rte_cryptodev_raw_enqueue_done`` > > > is > > > +called, the driver will initiate the processing of all enqueued desc= riptors > > and > > > +merge the temporary queue pair data changes into the driver's privat= e > > queue > > > +pair data. Calling ``rte_cryptodev_raw_configure_dp_context`` twice > > without > > > +``rte_cryptodev_dp_enqueue_done`` call in between will invalidate th= e > > > temporary > > > +data stored in ``struct rte_crypto_raw_dp_ctx`` buffer. This feature= is > > useful > > > +when the user wants to abandon partially enqueued data for a failed > > 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 wa= y > > to bypass > > this done API? >=20 > 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? Can the enqueue/dequeue API return a flag which decide whether to call done API or not? Returning ENOTSUP will break the execution. > > > +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 t= ime > > and other > > From an argument. >=20 > 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 fu= nction > handler based on the session data. Using of the same PMD callback functio= n is > to > save one function pointer stored in the dev_ops. If you don't like it I c= an create > 2 callback functions no problem. I don't like the idea of having 2 APIs. 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 ch= anged?