From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 09A15A0579; Thu, 8 Apr 2021 16:56:54 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E97D41410E1; Thu, 8 Apr 2021 16:56:53 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by mails.dpdk.org (Postfix) with ESMTP id D98504068B for ; Thu, 8 Apr 2021 16:56:51 +0200 (CEST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 138EejBt022248; Thu, 8 Apr 2021 07:56:51 -0700 Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2175.outbound.protection.outlook.com [104.47.59.175]) by mx0a-0016f401.pphosted.com with ESMTP id 37shqxkjq2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 08 Apr 2021 07:56:50 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OPay3y20GVxlHU+XAkLQgFrsmeoKk8Bi16PSFUW/JBVxCX4NsGzYJD/G0rV/+mudyBVhyg+tVfmEr8PuAGMI1QqT3DIWxmB0LUWVnlwlEz3WaVIaUfxuM/5c0fYSP6Yh9FLxFN+q+IIEoYkgeP7+JsLs8Wdc+EGy21g2qMSwlIRIBVY+k69brZpLmCEoeGP9KTtf4Wbjy2F3PnsKo25QG4XpvH3jZ0NMfeLeIcBMthujG3DdCg67lHRX28Kam36or6tw614IRDmCWrb4aeg06JYg4w3o8lsEUxaxXtjhniL5EoZwToC+nhSEICjmWyI6Wouag/ohHWm79g8c3rtfIw== 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=HvfVONKQkqabjRuK/PnOHBYKbbW5X0FVJQkvVuebS1k=; b=MBzGWQbqaUNmUUntsCWxeIkKjux7aI4tLuWhR/xO9ilWump3FvWS88cobJBclCPhoLBKQF7Ly1kqhw2KDVbgWJN/FUOyTiuLNmlk3f06OnD8yzdmqnts9ACMP6OJU+6+OTbhOAdzTblbhQ0DT6fvjHt5dEvymSbGd0D6fiAjNtvEETUAPSg98D7+r0ENAA3f9Py8tkRDLElDVtEMKSaCwg8QgmlWxxOk9xDHyVZK7VABJvsAzo4cFGQi/f8+HA4FzhavnhTm6JJFiuGHE+sp98KFo67Hq2YJZCpmIMDO75EZGLMmHMsCEcfu5LRkqw2PuYjEotWDUgYI4oetBJDrJQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=marvell.com; dmarc=pass action=none header.from=marvell.com; dkim=pass header.d=marvell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector1-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HvfVONKQkqabjRuK/PnOHBYKbbW5X0FVJQkvVuebS1k=; b=oQ996ZQvuW5w+D7mRrPeRsNA5omJdRaUbILKLCk0WxfOCb/Rg/isqhLKjs7bPJrDiUYMVe7jd4usTpbB4+tHu++WR/lgJPvrrry1IgfpZuMtIMD5JEfIrBvbwIguZcVtYDIgWPeuIHuAb3xZXx/gsi/e5d+umXwPU/R0fXnOlJY= Received: from MW2PR18MB2284.namprd18.prod.outlook.com (2603:10b6:907:10::16) by MWHPR18MB0992.namprd18.prod.outlook.com (2603:10b6:300:a1::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.16; Thu, 8 Apr 2021 14:56:47 +0000 Received: from MW2PR18MB2284.namprd18.prod.outlook.com ([fe80::3168:cb00:6607:743f]) by MW2PR18MB2284.namprd18.prod.outlook.com ([fe80::3168:cb00:6607:743f%7]) with mapi id 15.20.3999.035; Thu, 8 Apr 2021 14:56:47 +0000 From: Akhil Goyal To: "Gujjar, Abhinandan S" , Shijith Thotton , "dev@dpdk.org" CC: "thomas@monjalon.net" , Jerin Jacob Kollanukkaran , "hemant.agrawal@nxp.com" , "nipun.gupta@nxp.com" , "sachin.saxena@oss.nxp.com" , Anoob Joseph , "matan@nvidia.com" , "Zhang, Roy Fan" , "g.singh@nxp.com" , "Carrillo, Erik G" , "Jayatheerthan, Jay" , Pavan Nikhilesh Bhagavatula , "Van Haaren, Harry" Thread-Topic: [PATCH v4 1/3] eventdev: introduce crypto adapter enqueue API Thread-Index: AQHXJ+H7QHX7fl5iEU6e+axEBTKZ86qiuvUAgAN2uaCAAwPbgIABExxQ Date: Thu, 8 Apr 2021 14:56:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: 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=marvell.com; x-originating-ip: [182.69.47.6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b12fdf17-cc94-4467-b0f2-08d8fa9e884a x-ms-traffictypediagnostic: MWHPR18MB0992: 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: cxo7+ivpqJ36WlsliCFC3+dh8WfzKqEgBlIfUOJYzWevrFFbGllr/pane28d8RP6zw414b9Ep6Kh3w/NGYt5UoVjjNuJEoq2fM09ERqEIHxQgj0p4t27V44D/Ym4VJF5FgF8eL26XciVGs8wHULoSr4M4AdLO7McdxD/3RVlm1NnubUoZjj5WELmozvPRNgt2OJfPUnBh/5ZNO7Q2bCTRGX1fj98iHRGjoQ8fsJ0I/C2Ec0rspuoEZzUqcY/aE9+G58X2VyfQDnmBO03QXZItlcBEQVDIfnA7T4JkA91B8dTRCqVf0ko1cgWLRcINFcNPAPwOk0nmxelWCrT3/6ChuaJYwxdUJiVwfC/+9fjFtGvEI/fOuDNliOZ5/TeMkfyoPc8B9Mn7JltXqUTyK49r/eYpgV2MgKZUCfi5inxiwpeAQutna+bzybwK0JTpVqWpWjb4sWLHCBEA+oHgLVWvQTIglhahT68266cy/XECZpwEqY3MNPxwpl5NdjfVUfpnCeTRLuV4/ytGJUUdZ3pvdkURanCGzR5BHvtPBT3mOaUy/3v5qQAWOwMoUUEw/xWED8T3O+mIuh8t1DiJSI2bRc0JhZpCHay0w+Bk3T1XnLVTveO/DI2Qy1bB7thI1NSvkBVqd56TJqGaXAgmPCwlBo9qg/kHHwMdYRLih49deI= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW2PR18MB2284.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(39860400002)(396003)(346002)(376002)(9686003)(7696005)(86362001)(8676002)(71200400001)(478600001)(83380400001)(55016002)(316002)(186003)(38100700001)(2906002)(33656002)(66946007)(52536014)(26005)(8936002)(76116006)(66476007)(66556008)(54906003)(7416002)(110136005)(5660300002)(66446008)(64756008)(6506007)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?Z+qcLmtjxAWEFi+nLBvOGaZVB5QBeGfx7k4en0cRq2xZ5H20mPSNmSfxN+bi?= =?us-ascii?Q?Vq2Y1QId99rIToEl9928Y9Q9JF+qzZIlTKDL3v/xVN95G+EZ0tnmmWDbA2fb?= =?us-ascii?Q?KrvHmueBVTFcp34y5DrVb6H7idF+qZ+OsCXsMdX0hfJDz8vJMokPfAb7JWsF?= =?us-ascii?Q?WneAStRv2on11bQcV6q1qNFtce5JIr+Hk2AnI5n4X36hSt192dyBQEI9UGiK?= =?us-ascii?Q?PnInUtBzJwY93cLB7ud1n51a5KSdzvRLJ2z5SBNXBhxfHR+2anVKQ/SI6Fme?= =?us-ascii?Q?+G9D0qtvA74fIyFqSfbWmOEDkm5ExlEuPFmclCE9sjWjxgALBFkh2ZAruqIq?= =?us-ascii?Q?7cXoALqUoNEaAAStD1AeZSY6R60Uf7mdguIuhS0l36CCaEEi8Y+toSZ+fujD?= =?us-ascii?Q?soGbBiaAog0QvL3fju/u0WZLM0tkaTduKNkyNNvoV1rCfFjxdce1zKOuQwWl?= =?us-ascii?Q?OkzEJArFehsm0dORWornFOEb27wz21nIRQk7wrgbO+3/g7fiSfsqVQqrpARO?= =?us-ascii?Q?xxLwBJgERPOUTf751nDi8WrPDTaZvYlFwvqFTmmVqQC5tIjgydKboZ9Q/6FD?= =?us-ascii?Q?gTPvRIAUdC6SxZ7yBOarrpvalHHFQZ4GFjxauIxDNGunZ1DHXTdjQsv78/LI?= =?us-ascii?Q?0wwPuON7iHf5q/6JC1iASI1cuI98khwTvVFFJKGqP2dfWUqBW3YwWkY0rSo3?= =?us-ascii?Q?VtBeYhf+DCxVOiHZXCIypALvm4ovNoQK8R44Vn607pi5LlBg6rWvgtCdGgWR?= =?us-ascii?Q?iKh1BVjQgWUOh1ykd8P58kjPffqpis8iYcGatBNG1axFavhgPeyVk6OnNnkF?= =?us-ascii?Q?yBqtDQUONlpu9MatiLWZ/meYRndWw5VmbGeTPhR+UOHZDIW58HUXLhp/7gkg?= =?us-ascii?Q?gvdjacyVmBw1MiGd3ta+7aqpJqSav6QySQyEYv7bMaw5nY2DXPCny4Y8ToxU?= =?us-ascii?Q?UFpaMAkV0Ol0SijZSpkbqwm3TOLcw0cKK9s+OkmCvNFoCD4qY4BDYe3DwLso?= =?us-ascii?Q?BsyavCsOhmNzfsHP48K7DHvn9daGR1kto3uL2JZ+t0CcNegCJx3AD4H4pQ6F?= =?us-ascii?Q?2RsXMnAVez8BJqRKH422BAboA/JcBz2OvrUsQRyavsV0ACtXktOuZYolBYNE?= =?us-ascii?Q?WXvChovdjwiL6ABbpUjOBENz66FuFQZbI2G5P78nEnowSDCXdHKaUgWfKbFm?= =?us-ascii?Q?Py5jvzyrFYoM5RLyC8KEiAeMNBRGwIhNiwRRHBVLIt3Hb/NA1RP0oFVSIMSW?= =?us-ascii?Q?J4yGSMCIsKe5UN3+mPShOtqGTodUjO2YNrlXKjvJ0B4Qya7+6Vn9+FR1vc5O?= =?us-ascii?Q?vOY=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: marvell.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW2PR18MB2284.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b12fdf17-cc94-4467-b0f2-08d8fa9e884a X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2021 14:56:46.8939 (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: KJF7fdMLdplX+S71TPL4j0ccsY59uWfhFScvFG9m3miaADYYSDgGzizUsGFLIOQfN0eAb6N5lmxMLY0pDKd8Vw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR18MB0992 X-Proofpoint-ORIG-GUID: DZ6kK_H3issm9TrFJzla2DmFTz_BDXlX X-Proofpoint-GUID: DZ6kK_H3issm9TrFJzla2DmFTz_BDXlX X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-08_03:2021-04-08, 2021-04-08 signatures=0 Subject: Re: [dpdk-dev] [PATCH v4 1/3] eventdev: introduce crypto adapter enqueue API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 Abhinandan, > > > > > > > > In case an event from a previous stage is required to be forwarded > > > > to a crypto adapter and PMD supports internal event port in crypto > > > > adapter, exposed via capability > > > > RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD, we do > > not have a > > > > way to check in the API rte_event_enqueue_burst(), whether it is fo= r > > > > crypto adapter or for eth tx adapter. > > > I may be missing something here. Crypto adapter is an atomic stage ha= s > > > a port which is setup during the adapter configuration. > > > So, application enqueuing events will end up sending to the crypto > > > adapter (As the adapter dequeues from a specific port). > > > Still wondering why there is requirement for new API. > > > > While we do rte_event_enqueue_burst(), we do not have a way to identify > > whether The event is for crypto adapter or the eth adaptor. > > At the application layer, we know where to send the event, but in the e= vent > > lib We do not know which port it need to be sent. > > IMO, event port is specifically designed to work for OP_NEW mode. > > I did not find a way to make it land into crypto adapter. > > Please let me know in case there is a better option other than adding a= new > > API. > This looks like a hack as the new API does not actual enqueue events to > eventdev. > Rather it directly extracts the crypto info from each event and then enqu= eue > to cryptodev. >=20 > How about doing this (No changes to rte_event_enqueue_burst(), PMD takes > care of things ): > uint16_t __rte_hot > ssows_enq_burst(void *port, const struct rte_event ev[], uint16_t nb_even= ts) > { > + struct otx2_ssogws *ws =3D port; > + > + RTE_SET_USED(nb_events); > + > + if (cap & > RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD) > + return otx2_ca_enq(ws->tag_op, ev); >=20 > return ssows_enq(port, ev); > } >=20 > Everything will be hidden under the callback and application will not hav= e > any changes. >=20 You want to say we somehow save a flag in struct otx2_ssogws from the capab= ility And check that flag here to enq to crypto. But that will not work, as the e= vents coming In this API can be for both crypto as well as eth tx adapter. If this check= is there, all events will go to crypto adapter. In the library or the driver, we do not have a mechanism to determine the d= estination of the event (Note that event type is for source of event and not destinati= on). Using some fields of rte_event will be a hack IMO. The solution proposed in this patchset is not a hack. Here is a reasoning t= o it: - The application when dequeues an event from the previous stage, knows wha= t to do with the event - send it to crypto or send to ethernet. Hence it makes sens= e to call the different API there itself as inside the rte_event_enqueue_burst() there is= no way to determine if it is for crypto adapter or eth adapter. Moreover, the solution is very similar to what eth tx adapter already suppo= rt (a new API to enqueue). I hope this make things clearer now. Regards, Akhil > > > > > > > > > > > > > Hence we need a new API similar to > > > > rte_event_eth_tx_adapter_enqueue(), > > > > which can send to a crypto adapter. > > > > > > > > Note that RTE_EVENT_TYPE_* cannot be used to make that decision, as > > > > it is meant for event source and not event destination. > > > > And event port designated for crypto adapter is designed to be used > > > > for OP_NEW mode. > > > > > > > > Hence, in order to support an event PMD which has an internal event > > > > port > > > in > > > > crypto adapter (RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD mode), > > exposed > > > > via capability > > RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD, > > > > application should use rte_event_crypto_adapter_enqueue() API to > > > > enqueue events. > > > > > > > > When internal port is not > > > available(RTE_EVENT_CRYPTO_ADAPTER_OP_NEW > > > > mode), application can use API rte_event_enqueue_burst() as it was > > > > doing earlier, i.e. retrieve event port used by crypto adapter and > > > > bind its event queues to that port and enqueue events using the API > > > > rte_event_enqueue_burst(). > > > > > > > > Signed-off-by: Akhil Goyal