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 3DE8CA0C47; Mon, 20 Sep 2021 07:54:58 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AEF3E40DF7; Mon, 20 Sep 2021 07:54:57 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id 8E9A840DF5 for ; Mon, 20 Sep 2021 07:54:55 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10112"; a="223105171" X-IronPort-AV: E=Sophos;i="5.85,307,1624345200"; d="scan'208";a="223105171" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Sep 2021 22:54:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,307,1624345200"; d="scan'208";a="652462375" Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by orsmga005.jf.intel.com with ESMTP; 19 Sep 2021 22:54:54 -0700 Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) 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.2242.12; Sun, 19 Sep 2021 22:54:54 -0700 Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by ORSMSX611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Sun, 19 Sep 2021 22:54:53 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Sun, 19 Sep 2021 22:54:53 -0700 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.103) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Sun, 19 Sep 2021 22:54:52 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LKBf901zf7tCc7NBx5baJyBbXSt5IyKbkvbh96TyaONif4hXfeJQDbrxjzC29YPi9XW3d2Pczt40kxODXXjiSnXlyCwYqG6HzjUW4t5I2v8tW2Y9DU478372ukuwKu6rCGVURG2PLeABMHq04O1ugQ0laH8K2WySRv7mZHCE5AajTaEKMUJSPQ+S6Dm1aBuMGyZEm/zzIEy25p3/fOEK1DbbSnSe3OKS77+r+imc8j4ldC9GYmIPbrv5lQKCnTUOCiNVnNWb7kfT7zl7ckG9j7mhxTv5+LARlAsgCUVuf9dnxFhCq52qw2xTc1XRojSsV/bE9aaYueySqSGwqI9kww== 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; bh=VZJYOk7CVwftszsN9Scuw8qO+mi2ip1zeu515zlPKGI=; b=ZIH57oN4C+h36pUMusOnnzUqb20vPvjbOnjqR8NQA89QOyfCRiXy2S2jvQrOg01Kj/9dTM/ixtFXxOF1/ibIxmHFzJOptOfC1uDNqMX/ez8WWsmH3ebbLnR93leiRkZXsOSO4jc3CuLqDZIWnVGJafBzyBw76epxLTE4hBwpmO6ze+3Q2n2qmarcikiwpgOD32UFKWI4ZbUhWT9RaQCo/Tusbe1yLI4Wyx0ECDgTWYhB4BFiDrl1F8eaZmm7Ztk9QjxKAPYrNUTqLobRz5Dxcj0aoUY26WpnIqNATAK4yRUN5e4bYDWBXoz1JDFzoLHMQTxTjgkfvpXOEJnjsGCxcw== 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=VZJYOk7CVwftszsN9Scuw8qO+mi2ip1zeu515zlPKGI=; b=O6+5ygOE89QvY/tGDdPCNwsKsvdleB1F044eOMTjMnTurEbpHCoLUf7bU0YHbo9c345ca2z7r1aMih8D0RKNoicJI9YppCP/75bmvI4rcnGB0/LJxBxjf8T5ytgD4o2hlLEv1GkiovE5iu+rrDRP0pxoRxv07+Hj0bmpoj8aIyY= Received: from PH0PR11MB4824.namprd11.prod.outlook.com (2603:10b6:510:38::13) by PH0PR11MB4886.namprd11.prod.outlook.com (2603:10b6:510:33::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.14; Mon, 20 Sep 2021 05:54:51 +0000 Received: from PH0PR11MB4824.namprd11.prod.outlook.com ([fe80::aca2:cce5:bef2:8a27]) by PH0PR11MB4824.namprd11.prod.outlook.com ([fe80::aca2:cce5:bef2:8a27%2]) with mapi id 15.20.4523.018; Mon, 20 Sep 2021 05:54:51 +0000 From: "Gujjar, Abhinandan S" To: Akhil Goyal , Anoob Joseph , Shijith Thotton CC: Jerin Jacob Kollanukkaran , "Pavan Nikhilesh Bhagavatula" , Ray Kinsella , "Ankur Dwivedi" , "dev@dpdk.org" , "thomas@monjalon.net" , "nipun.gupta@nxp.com" , Hemant Agrawal Thread-Topic: [PATCH v3] eventdev: update crypto adapter metadata structures Thread-Index: AQHXnj3WjnQgyKZ1dU+J5G+CJPvld6uYTrEggAAde4CAAHAWEIAA8W+AgAABoKCACThuAIAAAqoAgAh6tsCAAEx4AIAAsAXA Date: Mon, 20 Sep 2021 05:54:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.6.200.16 authentication-results: marvell.com; dkim=none (message not signed) header.d=none;marvell.com; dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a5e6cc72-620c-45df-0d14-08d97bfb29c4 x-ms-traffictypediagnostic: PH0PR11MB4886: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bMRU1in+YCM0PUkI86J1cpCBAnhKEP4GzS6w57vL0N9jcNIxpJm6OTGPqUWQBCD9N/X7HpK4cNQt2QR/8N4swxFmT3xjBeGLsCvKvLoAt8p9500ow6TeXyHlRoCDNis+8ssC2pdNtoxFHJx041EnIYtw9U68YHRf2tQjEbjYRlo7ma4QGjqK6sCHXQ4ZoJu2ri7ga+MEMnTh9zzcb8k7MHl7gEA5pDOpfS+Um8/SO+UqJkJGi5YHoBeGWybiwIpSDKBHdeVJFUn2DggCZ2kL1LmSV1mhdFqigpU6mT3jrjEovc7NzKhkBb65X5z8+tML+6zp1dOfhajjPARaZbsyAg14euRTVDODOE8v3SwdgdL0oAsw3EjO/xnVt6pWsNYz/9Gy/D6iTTgliJCXUvOUUAi0Uh/g4+3p9GSp+jWIUocOQvEjdo3ISMPxu2KTwD1U9+XmufA9djeV+cwSXxxjVL4/fZLJJh/cdZ0Ctvpzcfj+QAFPMZvW89Gm48mmF1yvvy5iVlyOoffKYCGdawhqKZWyF7g9/pT4LKtZwwnNp/wm+HLfZkb1aallpzvZf1ec7wzfmV9nuvvcI/ZPUqAR5Uk4Hnt/OkFHA2PyoZX+o/Ih21OsefiNM2MUGepMeeS7uoj1+oMrmZedvtspXXv9fM0v+wx5VTz2x7+5emgW7KQ78RuvAuRJCKkulaejOoHjGcggZL5/VwAk0bXSaFNeHsWNvbPlfAnxntaSo9sxoXQjxy0Ncf7p9gXy7neBNxVsG/ELHN7UtMXHOzh1SAuO3uFNCmbeYEpsK8YnVytvpmE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4824.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(54906003)(26005)(66476007)(8676002)(66946007)(71200400001)(66556008)(966005)(508600001)(83380400001)(4326008)(64756008)(316002)(86362001)(5660300002)(110136005)(38070700005)(7696005)(45080400002)(33656002)(8936002)(38100700002)(2906002)(122000001)(186003)(15650500001)(6506007)(76116006)(53546011)(7416002)(52536014)(9686003)(55016002)(66446008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?9v6+1SdENHDvO06LPn7B/wWDi8x8lU8xtr5cIQ51dvWuPotNj4ZVFvkPyK14?= =?us-ascii?Q?gIq1ZXddWyMb83qGMFXtl7oDLC+6JrV0uW7slOY287UMTtjGXlbx7a/qccF/?= =?us-ascii?Q?ReBWs2tj5GPdwNlmitgd+3B1OahSrciFovg3/w/NR31yvxqkdYbDbU9mj+nO?= =?us-ascii?Q?szZ1OZ8YTwZOwzAFRY2x5vjZ7Jx8C/OAlhnEWyLxNtVgqSRkGIFxNeMHffus?= =?us-ascii?Q?hRbcVEmq1vYGAqPkaNsuvygOJpeaMG6RfNuC+qLKmBqX7rYfHSV7rhIGSUYw?= =?us-ascii?Q?T4aX1XHAPCbsF28E3TD9eU0wN7WXg/cMkRAMP0lbE5eEy/PCM6fdZr7faa9w?= =?us-ascii?Q?/RuRIa1DpQfe96kUHRR/8gZEmU3yOWvz1xDCfNIdG35senXZ1iUDGf6Uu3ZG?= =?us-ascii?Q?seyk9Fh29oa19vqEHlUTxf00H0mUb8MSaoDKqu2KR9la+aUaFOGTqeEZuz4w?= =?us-ascii?Q?omFNgWq3ov7Hv5qoaHqBwBd9w9DGHh1MKPSNQLMifl5A3FlwzwtSP90WrumE?= =?us-ascii?Q?H3/u0M5rBwX6sra4ztBkB45Yl56u5HsK7Y/8Qf1HvitFmbZkkZYTQARcAIFK?= =?us-ascii?Q?cs72D02jnYf6nk4C9cpDEhZoPeBoCeTyIxIbeq2RBBY/j8eh5zZ8JoZK0l+q?= =?us-ascii?Q?axm0TlR/Ho39PK+zulCjifNSv9SugXXJ+Z+MsiUEvV0lws8P/fhuPATL0bvo?= =?us-ascii?Q?5+GgaVPiUbvmXhLmosSBBwyMzqfMaMCrkv8b2yvA4J+P2XXc620C4SGJ8cPD?= =?us-ascii?Q?PMYuiQK5gaX9B5WbrvNO5CLPB15OWHKixWipFtRYccmih0DM/43ufKJjCce/?= =?us-ascii?Q?Gxzv9XEXd7ZeiSh5uq5SHked0YPSHQEdZwPUKkgIpS8AwjYCiUuMzTxHTe++?= =?us-ascii?Q?gIjR6PkEVn69p2zYCctlywjA1hyK32ECg8H6Mf/OPjBbjwwSQSSTblJbb1yq?= =?us-ascii?Q?i9wEqlubFZO7IJHej6xsNhnKwdxDoZL0w4rfKreWQf7VsdVRABS/mf58vjqx?= =?us-ascii?Q?CXaeMDDiB4iKGzK2X7YEIgGe4QaazR2M8nb4QOOU7e2EGJVY/roNbwVgpT4i?= =?us-ascii?Q?0mwgaSCAq/U5WZq2pqZXOfhTlHpSD3Mn+mcBhAuysVbIiowE1v4KIsvLJWOp?= =?us-ascii?Q?We+UaTvVY0EouTwZ00yHilVlmYJzUNESqrLKduH8Q9oUf0ZCUqNkHrHPZn26?= =?us-ascii?Q?9qfq614BbNb7zJzTHJ0g/c1srqgerRNNYOjW207HMlpPkfvTOU1wFRBjcn7D?= =?us-ascii?Q?DS2Hg3PXcREKmfDyONsRQ+2+bUyb+GEUFHqW244yDVpyLIuZjJIgmfdpIUib?= =?us-ascii?Q?cyy0mKNqreQ1I2JR8dJlXVjh?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4824.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a5e6cc72-620c-45df-0d14-08d97bfb29c4 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2021 05:54:51.6421 (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: fYmGxQO9sGw25uAnptYsXgfQtwoEHs38cRY33menBTE6ZMgxaMrH5YKzUL8kUSNNmc0f+ugnUMM4mJGTYcl5Mxqm9X6Zy6yLfcLGigUCfl4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4886 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v3] eventdev: update crypto adapter metadata structures 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 Akhil, > -----Original Message----- > From: Akhil Goyal > Sent: Monday, September 20, 2021 12:19 AM > To: Gujjar, Abhinandan S ; Anoob Joseph > ; Shijith Thotton > Cc: Jerin Jacob Kollanukkaran ; Pavan Nikhilesh > Bhagavatula ; Ray Kinsella ; > Ankur Dwivedi ; dev@dpdk.org; > thomas@monjalon.net; nipun.gupta@nxp.com; Hemant Agrawal > > Subject: RE: [PATCH v3] eventdev: update crypto adapter metadata > structures >=20 > Hi Abhinandan, > > > > >> >> > > > > >> >> >> In crypto adapter metadata, reserved bytes in request > > > > >> >> >> info structure is a space holder for response info. It > > > > >> >> >> enforces an order of operation if the structures are > > > > >> >> >> updated using memcpy to avoid overwriting response info. > > > > >> >> >> It is logical to move the reserved space out of request > > > > >> >> >> info. It also solves the ordering issue > > > > >> mentioned before. > > > > >> >> >I would like to understand what kind of ordering issue you > > > > >> >> >have faced with the current approach. Could you please give > > > > >> >> >an example/sequence > > > > >> >> and explain? > > > > >> >> > > > > > >> >> > > > > >> >> I have seen this issue with crypto adapter autotest (#n215). > > > > >> >> > > > > >> >> Example: > > > > >> >> rte_memcpy(&m_data.response_info, &response_info, > > > > >> >> sizeof(response_info)); rte_memcpy(&m_data.request_info, > > > > >> >> &request_info, sizeof(request_info)); > > > > >> >> > > > > >> >> Here response info is getting overwritten by request info. > > > > >> >> Above lines can reordered to fix the issue, but can be > > > > >> >> ignored with this > > > > >> patch. > > > > >> >There is a reason for designing the metadata in this way. > > > > >> >Right now, sizeof (union rte_event_crypto_metadata) is 16 bytes= . > > > > >> >So, the session based case needs just 16 bytes to store the dat= a. > > > > >> >Whereas, for sessionless case each crypto_ops requires another > > > > >> >16 > > > > bytes. > > > > >> > > > > > >> >By changing the struct in the following way you are doubling > > > > >> >the memory requirement. > > > > >> >With the changes, for sessionless case, each crypto op > > > > >> >requires 32 bytes of space instead of 16 bytes and the mempool > will be bigger. > > > > >> >This will have the perf impact too! > > > > >> > > > > > >> >You can just copy the individual members(cdev_id & > > > > >> >queue_pair_id) after the response_info. > > > > >> >OR You have a better way? > > > > >> > > > > > >> > > > > >> I missed the second word of event structure. It adds an extra 8 > > > > >> bytes, which is not required. > > > > >I guess you meant not adding, it is overlapping with request > > information. > > > > >> Let me know, what you think of below change to metadata > structure. > > > > >> > > > > >> struct rte_event_crypto_metadata { > > > > >> uint64_t response_info; // 8 bytes > > > > >With this, it lags clarity saying it is an event information. > > > > >> struct rte_event_crypto_request request_info; // 8 bytes }; > > > > >> > > > > >> Total structure size is 16 bytes. > > > > >> > > > > >> Response info can be set like below in test app: > > > > >> m_data.response_info =3D response_info.event; > > > > >> > > > > >> The main aim of this patch is to decouple response info from > > > > >> request > > > info. > > > > >The decoupling was required as it was doing memcpy. > > > > >If you copy the individual members of request info(after > > > > >response), you don't require it. > > > > > > > > With this change, the application will be free of such constraints. > > > > > > [Anoob] Why don't we make it like, > > > > > > struct rte_event_crypto_metadata { > > > uint64_t ev_w0_template; > > > /**< Template of the first word of ``struct > > > rte_event`` > > > (rte_event.event) to be set in the events generated by crypto > > > adapter in both RTE_EVENT_CRYPTO_ADAPTER_OP_NEW and > > > * RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD modes. > > > */ > > > struct rte_event_crypto_request request_info; }; > > > > > > This way, the usage would become more obvious and we will not have > > > additional space reserved as well. > > > > Thanks for the suggestion. At this point, it is like an application > > without understanding the data structure/ internals has used memcpy > > and we are trying to fix it by changing the actual data structure > > instead of fixing the application! > > With this patch, the other applications(outside of dpdk) which are > > using the data structures in a right are forced to change! > > I don't think, this is the right way to handle this. I think, we > > should be updating the test case and documentation for this rather > > than changing the data structure. I expect the next version of this > > patch should have those changes. Thanks! >=20 > The point here is about making the specification better and clearer to th= e > user. > If the structure is not clear and is error prone if somebody does not fol= low > Proper documentation, we can modify it to reduce possible issues. I think, the structure is clear. Apart from adding documentation, I feel forming a structure with appropriate data type and naming it to make= it self-explanatory is important. That is what we have done, and this is already discussed in the original pa= tch as well. It is important for any application writer to go through the documentation = and structure to understand before using it. The current documentation clearing says it has overlap. If you still feel i= t lags clarity in some places please go ahead and add documentation. It is not about the ABI breakage; it is about changing a proper structure f= or an ignorant application! I am not convinced with the proposed changes. If you have a better one, ple= ase let me know. >=20 > This is a cleanup which was added in deprecation notice as well in the la= st > release. > This is a ABI break release and we should do this cleanup if it is legit. > Applications outside DPDK are notified as per the deprecation notice in t= he > last release. > We have followed standard procedure to modify this structure, hence, no > need to worry about that. > We have provided, 2-3 suggestions to clean this up. Please suggest which > one is best for Intel use case. >=20 > Having first element as reserved in the structure doesn't look quite obvi= ous. > This was also highlighted in the original patch, but was not taken up ser= iously > as we were not supporting it at that point. > See this > http://patches.dpdk.org/project/dpdk/patch/1524573807-168522-2-git- > send-email-abhinandan.gujjar@intel.com/ >=20 > -Akhil >=20 > Please note: > Avoid top posting for comments and remove unnecessary lines while > commenting back. >=20 Please note that, I am using outlook with appropriate settings to respond b= ack. I am not sure, why this is coming as top posting.