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 192C6425FF; Thu, 21 Sep 2023 12:55:21 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E1758402C7; Thu, 21 Sep 2023 12:55:20 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by mails.dpdk.org (Postfix) with ESMTP id 71BAF402B5 for ; Thu, 21 Sep 2023 12:55:19 +0200 (CEST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 38L7SXe9007707; Thu, 21 Sep 2023 03:55:18 -0700 Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2041.outbound.protection.outlook.com [104.47.66.41]) by mx0b-0016f401.pphosted.com (PPS) with ESMTPS id 3t85pttu81-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Sep 2023 03:55:18 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YAjvl/pcyov8KwUbWd/UzAqq+Ke5rzvKr2xlwdt51PB28NAicWe8Nf32hTIzGoI2TGnTTNBTGWQIwaxnNDLFoV3ogSA103DjBvxvjQ/mvhS3OMOvVuVX/1JUbltq3WfucMjnLZs0K99pnsHlsGOQbRuoE398vhi532bIhUXWaqc3icbJG9XKhq1buPSyv+JBbHibj/OjoxakPFhLyUPRXfs2nMBZ9HTjs5lD019DG54L6FGdgp85XHp/CJ50qkXtmYKk7ZOcVHHbMycej1mooAny7sBP4eAhkYdOocXAmfAtJ9dQPxwX8CXH0ahGCFu9ONl34NLetqI9lHMZ6JibbQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tVtjf6VdaGqDfo0nXMahrSbC7Tgw+EaPNSrHB3yicSs=; b=KWbJS4CiTDc6U+1bf3SPD+pD9/9EIVI43GIDYipWznuJZe7CKhggRaB7xv+EnFaku2aBUUy6KlOcKe1BPoPw7L77SKszN5XkLR6cZ0EEYOkGK7T2UYBT5suO9h+buHsubuk6xQH9L8x8VINWDhLWHgwUabxvHNLxYyjtsPqcrp8kDKB1Z9tDxliVFMqjH1uc/dARkttgIG0MrL6s9prldwg22ZcErkvjMzDflop/Y3vjBoG9KeklyTc0e567Nui9AzqB3/s3VUnZlTrwUD/EtHeJpUs1/p6v7FnavxD7EcNM9vTG+xQwelWqPfK1G2qGC5XU2s5c7Z5/JtaVt37m3Q== 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=tVtjf6VdaGqDfo0nXMahrSbC7Tgw+EaPNSrHB3yicSs=; b=A6B0EzqNDNDiRN/X5s8TJemK4tW5i6n4HgVHB7+G0c/PzFaZobGIF/yHmCzThhANGNOQ5K6o5KM4Xpi42dQ5Nzo19WDOD2SMfFVwn54QeNOkigDlhtx+8FnHlQOfgR1lof1gi1cxcDyJiPdMG4feDspxSE+2SeTXCrsQ0baK2AA= Received: from PH0PR18MB4672.namprd18.prod.outlook.com (2603:10b6:510:c9::16) by DM4PR18MB5405.namprd18.prod.outlook.com (2603:10b6:8:17f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6813.21; Thu, 21 Sep 2023 10:55:13 +0000 Received: from PH0PR18MB4672.namprd18.prod.outlook.com ([fe80::cd84:2ed1:5222:7527]) by PH0PR18MB4672.namprd18.prod.outlook.com ([fe80::cd84:2ed1:5222:7527%6]) with mapi id 15.20.6792.026; Thu, 21 Sep 2023 10:55:13 +0000 From: Anoob Joseph To: "Van Haaren, Harry" CC: Hemant Agrawal , "dev@dpdk.org" , "Matz, Olivier" , Vidya Sagar Velumuri , Thomas Monjalon , Akhil Goyal , Jerin Jacob Kollanukkaran , Konstantin Ananyev Subject: RE: [RFC PATCH 2/3] security: add TLS record processing Thread-Topic: [RFC PATCH 2/3] security: add TLS record processing Thread-Index: AQHZ66QdZuZNVqm6c0mtvwyxk/2qYbAjke7ggAFkygCAABXhgA== Date: Thu, 21 Sep 2023 10:55:13 +0000 Message-ID: References: <20230811071712.240-1-anoobj@marvell.com> <20230811071712.240-3-anoobj@marvell.com> In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-rorf: true x-dg-ref: =?us-ascii?Q?PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNcYW5vb2JqXGFw?= =?us-ascii?Q?cGRhdGFccm9hbWluZ1wwOWQ4NDliNi0zMmQzLTRhNDAtODVlZS02Yjg0YmEy?= =?us-ascii?Q?OWUzNWJcbXNnc1xtc2ctNTQ1ZGE5MGYtNTg2ZC0xMWVlLTljNjYtNGMwMzRm?= =?us-ascii?Q?NWY5YjRmXGFtZS10ZXN0XDU0NWRhOTEwLTU4NmQtMTFlZS05YzY2LTRjMDM0?= =?us-ascii?Q?ZjVmOWI0ZmJvZHkudHh0IiBzej0iMTg4MDMiIHQ9IjEzMzM5NzY3MzEwMTky?= =?us-ascii?Q?OTI3NSIgaD0iV0t3NllRTjJoT1J6aU85S1ZNOUtibXlmUzJNPSIgaWQ9IiIg?= =?us-ascii?Q?Ymw9IjAiIGJvPSIxIiBjaT0iY0FBQUFFUkhVMVJTUlVGTkNnVUFBTjRQQUFB?= =?us-ascii?Q?N3F4b1hldXpaQVhhRExaSGVYU0o3ZG9NdGtkNWRJbnNaQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUhBQUFBQnVEd0FBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUVBQVFFQkFBQUE5UmVuTHdDQUFRQUFBQUFBQUFBQUFKNEFBQUJoQUdRQVpB?= =?us-ascii?Q?QnlBR1VBY3dCekFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?RUFBQUFBQUFBQUFnQUFBQUFBbmdBQUFHTUFkUUJ6QUhRQWJ3QnRBRjhBY0FC?= =?us-ascii?Q?bEFISUFjd0J2QUc0QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQVFBQUFBQUFBQUFDQUFB?= =?us-ascii?Q?QUFBQ2VBQUFBWXdCMUFITUFkQUJ2QUcwQVh3QndBR2dBYndCdUFHVUFiZ0Ix?= =?us-ascii?Q?QUcwQVlnQmxBSElBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUJBQUFBQUFBQUFBSUFBQUFBQUo0QUFBQmpBSFVB?= =?us-ascii?Q?Y3dCMEFHOEFiUUJmQUhNQWN3QnVBRjhBWkFCaEFITUFhQUJmQUhZQU1BQXlB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= x-dg-refone: =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFFQUFBQUFBQUFBQWdBQUFBQUFuZ0FBQUdN?= =?us-ascii?Q?QWRRQnpBSFFBYndCdEFGOEFjd0J6QUc0QVh3QnJBR1VBZVFCM0FHOEFjZ0Jr?= =?us-ascii?Q?QUhNQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBUUFBQUFBQUFBQUNBQUFBQUFDZUFBQUFZd0IxQUhNQWRBQnZBRzBB?= =?us-ascii?Q?WHdCekFITUFiZ0JmQUc0QWJ3QmtBR1VBYkFCcEFHMEFhUUIwQUdVQWNnQmZB?= =?us-ascii?Q?SFlBTUFBeUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQkFBQUFBQUFB?= =?us-ascii?Q?QUFJQUFBQUFBSjRBQUFCakFIVUFjd0IwQUc4QWJRQmZBSE1BY3dCdUFGOEFj?= =?us-ascii?Q?d0J3QUdFQVl3QmxBRjhBZGdBd0FESUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUVBQUFBQUFBQUFBZ0FBQUFBQW5nQUFB?= =?us-ascii?Q?R1FBYkFCd0FGOEFjd0JyQUhrQWNBQmxBRjhBWXdCb0FHRUFkQUJmQUcwQVpR?= =?us-ascii?Q?QnpBSE1BWVFCbkFHVUFYd0IyQURBQU1nQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFRQUFBQUFBQUFBQ0FBQUFBQUNlQUFBQVpBQnNBSEFBWHdCekFH?= =?us-ascii?Q?d0FZUUJqQUdzQVh3QmpBR2dBWVFCMEFGOEFiUUJsQUhNQWN3QmhBR2NBWlFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= x-dg-reftwo: =?us-ascii?Q?QUFBQUFBQUFBQUFCQUFBQUFBQUFBQUlBQUFBQUFKNEFBQUJrQUd3QWNBQmZB?= =?us-ascii?Q?SFFBWlFCaEFHMEFjd0JmQUc4QWJnQmxBR1FBY2dCcEFIWUFaUUJmQUdZQWFR?= =?us-ascii?Q?QnNBR1VBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBRUFB?= =?us-ascii?Q?QUFBQUFBQUFnQUFBQUFBbmdBQUFHVUFiUUJoQUdrQWJBQmZBR0VBWkFCa0FI?= =?us-ascii?Q?SUFaUUJ6QUhNQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFLZ0FBQUFBQUFBQUFBQUFBQVFBQUFBQUFBQUFDQUFBQUFB?= =?us-ascii?Q?Q2VBQUFBYlFCaEFISUFkZ0JsQUd3QVh3QndBSElBYndCcUFHVUFZd0IwQUY4?= =?us-ascii?Q?QWJnQmhBRzBBWlFCekFGOEFZd0J2QUc0QVpnQnBBR1FBWlFCdUFIUUFhUUJo?= =?us-ascii?Q?QUd3QVh3QmhBR3dBYndCdUFHVUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUJBQUFBQUFBQUFBSUFBQUFBQUo0QUFBQnRBR0VBY2dC?= =?us-ascii?Q?MkFHVUFiQUJmQUhBQWNnQnZBR29BWlFCakFIUUFYd0J1QUdFQWJRQmxBSE1B?= =?us-ascii?Q?WHdCeUFHVUFjd0IwQUhJQWFRQmpBSFFBWlFCa0FGOEFZUUJzQUc4QWJnQmxB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFF?= =?us-ascii?Q?QUFBQUFBQUFBQWdBQUFBQUFuZ0FBQUcwQVlRQnlBSFlBWlFCc0FGOEFjQUJ5?= =?us-ascii?Q?QUc4QWFnQmxBR01BZEFCZkFHNEFZUUJ0QUdVQWN3QmZBSElBWlFCekFIUUFj?= =?us-ascii?Q?Z0JwQUdNQWRBQmxBR1FBWHdCb0FHVUFlQUJqQUc4QVpBQmxBSE1BQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBUUFBQUFBQUFBQUNBQUFB?= =?us-ascii?Q?QUFDZUFBQUFiUUJoQUhJQWRnQmxBR3dBYkFCZkFHRUFjZ0J0QUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= x-dg-refthree: =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQkFBQUFBQUFBQUFJ?= =?us-ascii?Q?QUFBQUFBSjRBQUFCdEFHRUFjZ0IyQUdVQWJBQnNBRjhBWndCdkFHOEFad0Jz?= =?us-ascii?Q?QUdVQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUVBQUFBQUFBQUFBZ0FBQUFBQW5nQUFBRzBB?= =?us-ascii?Q?WVFCeUFIWUFaUUJzQUd3QVh3QndBSElBYndCcUFHVUFZd0IwQUY4QVl3QnZB?= =?us-ascii?Q?R1FBWlFCekFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFRQUFBQUFBQUFBQ0FBQUFBQUNlQUFBQWJRQmhBSElBZGdCbEFHd0Fi?= =?us-ascii?Q?QUJmQUhBQWNnQnZBR29BWlFCakFIUUFYd0JqQUc4QVpBQmxBSE1BWHdCa0FH?= =?us-ascii?Q?a0FZd0IwQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFCQUFBQUFBQUFB?= =?us-ascii?Q?QUlBQUFBQUFKNEFBQUJ0QUdFQWNnQjJBR1VBYkFCc0FGOEFjQUJ5QUc4QWFn?= =?us-ascii?Q?QmxBR01BZEFCZkFHNEFZUUJ0QUdVQWN3QmZBR01BYndCdUFHWUFhUUJrQUdV?= =?us-ascii?Q?QWJnQjBBR2tBWVFCc0FGOEFiUUJoQUhJQWRnQmxBR3dBYkFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBRUFBQUFBQUFBQUFnQUFBQUFBbmdBQUFH?= =?us-ascii?Q?MEFZUUJ5QUhZQVpRQnNBR3dBWHdCd0FISUFid0JxQUdVQVl3QjBBRjhBYmdC?= =?us-ascii?Q?aEFHMEFaUUJ6QUY4QVl3QnZBRzRBWmdCcEFHUUFaUUJ1QUhRQWFRQmhBR3dB?= =?us-ascii?Q?WHdCdEFHRUFjZ0IyQUdVQWJBQnNBRjhBYndCeUFGOEFZUUJ5QUcwQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= x-dg-reffour: =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQVFBQUFBQUFBQUFDQUFBQUFBQ2VB?= =?us-ascii?Q?QUFBYlFCaEFISUFkZ0JsQUd3QWJBQmZBSEFBY2dCdkFHb0FaUUJqQUhRQVh3?= =?us-ascii?Q?QnVBR0VBYlFCbEFITUFYd0JqQUc4QWJnQm1BR2tBWkFCbEFHNEFkQUJwQUdF?= =?us-ascii?Q?QWJBQmZBRzBBWVFCeUFIWUFaUUJzQUd3QVh3QnZBSElBWHdCbkFHOEFid0Ju?= =?us-ascii?Q?QUd3QVpRQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUJBQUFBQUFBQUFBSUFBQUFBQUo0QUFBQnRBR0VBY2dCMkFH?= =?us-ascii?Q?VUFiQUJzQUY4QWNBQnlBRzhBYWdCbEFHTUFkQUJmQUc0QVlRQnRBR1VBY3dC?= =?us-ascii?Q?ZkFISUFaUUJ6QUhRQWNnQnBBR01BZEFCbEFHUUFYd0J0QUdFQWNnQjJBR1VB?= =?us-ascii?Q?YkFCc0FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFFQUFB?= =?us-ascii?Q?QUFBQUFBQWdBQUFBQUFuZ0FBQUcwQVlRQnlBSFlBWlFCc0FHd0FYd0J3QUhJ?= =?us-ascii?Q?QWJ3QnFBR1VBWXdCMEFGOEFiZ0JoQUcwQVpRQnpBRjhBY2dCbEFITUFkQUJ5?= =?us-ascii?Q?QUdrQVl3QjBBR1VBWkFCZkFHMEFZUUJ5QUhZQVpRQnNBR3dBWHdCdkFISUFY?= =?us-ascii?Q?d0JoQUhJQWJRQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBUUFBQUFBQUFBQUNBQUFBQUFD?= =?us-ascii?Q?ZUFBQUFiUUJoQUhJQWRnQmxBR3dBYkFCZkFIUUFaUUJ5QUcwQWFRQnVBSFVB?= =?us-ascii?Q?Y3dBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQkFBQUFBQUFBQUFJQUFBQUFBSjRBQUFCdEFHRUFjZ0Iy?= =?us-ascii?Q?QUdVQWJBQnNBRjhBZHdCdkFISUFaQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUVB?= =?us-ascii?Q?QUFBQUFBQUFBZ0FBQUFBQSIvPjwvbWV0YT4=3D?= x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PH0PR18MB4672:EE_|DM4PR18MB5405:EE_ x-ms-office365-filtering-correlation-id: 7d9f559e-550b-4646-9505-08dbba913b9f x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gdb31woGFOmaaO+CqTvncfISbprcYB+H2uVKpvP6Z1dsUJ7oAJfHeQhHqMRoOF3ykntMNtb833RuBbB1ydrUVYVfqzxRgfOkHvhf1n/5ZPeQAwvW0taz+HTpLua4t/cR+vGiv2tEkUh6DIR09EtZrT8m1eE0PMvV1DnhhzsdUkwpFIVGctG7Nzf2mOMIg2jbieZSHTyaZCgc2lJR+T4Xo1nuRIka2YO2BnypBPFpJmg6Y/nLFuJQKgnvFiATvdb9Fw4Jn83SDEW//EzUB7HEGs6WHwWlde7PEyNNY137xXhhhKdkMU6vuvanH+JsOGo+zfwtJVKVHsxRfzAApFgHfUfRfg2BBZXw54xCADGxNGb31TyPAQ8taVNFEfB6Wh4eZyqo68H5f8ZI6aeBrbs5xqHrBjx2hm50LnKl/XxWccJmoEXYinAooldqy2QhC5QzRoF4/v7GHQUpCwqUxOpyqPgtAF2kpS8L3sHu4a9isOD1/NmDqraAkoawQVmfl4nV3bNVqwn0TqeymTejPwTWbkn/3SLSgs5Lr1SLG0PTXfvUBjy95e6R+nEf55+PCCA4Tg2dtQsT59UXwglUVqZZ0sW2DV+b8052zDMjnSXsLrQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR18MB4672.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(366004)(376002)(346002)(136003)(39850400004)(396003)(186009)(1800799009)(451199024)(66899024)(55016003)(9686003)(26005)(38070700005)(316002)(38100700002)(6916009)(66946007)(66446008)(76116006)(64756008)(54906003)(66556008)(71200400001)(66476007)(41300700001)(478600001)(122000001)(966005)(53546011)(7696005)(6506007)(19627235002)(15650500001)(33656002)(2906002)(30864003)(83380400001)(86362001)(52536014)(8936002)(4326008)(8676002)(66574015)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?L8E7hBcSSarxVKDwfjQhxgvjIv00i8zlySTvxMI3yp8yjh73whFbdapCW5se?= =?us-ascii?Q?pSkjtlJq9YXMyUA74DN1C2cIwVTPRYxjejcG3D9VAYx/KGcf3BuB6DU0D6vj?= =?us-ascii?Q?Irwx1psy2Jy6T9yk6Ai0KLNCAnifEeohIziyIgeK6AM+WKfLAGQSrfZYpmmB?= =?us-ascii?Q?szKF22nvMaZHw8XoHjX0nVCGBjdB71eP30pM9yb0R264WZcVAW1FzabAqu+C?= =?us-ascii?Q?aG06RoqmymSIhPTaA/OzNUBe6nZmf+vogK3+aI6GO2SOvPR+NjMq33Yqiy6E?= =?us-ascii?Q?83zNIV4beb0rgYh6DRAFJTFL7IzC2WanNoRr+f9hElWhFwk07saUjbyGqQxK?= =?us-ascii?Q?stQCU12C/TX++ne6Eox+q5Po+l/y1KxN2J9i27Lfs+P5ncA5mTfRTPNw1SoV?= =?us-ascii?Q?qykAREgDGLNJJso4617SuWRj4f1DNZslEWMYMQ8hTsJeMnfSWsHEAcVa+v5R?= =?us-ascii?Q?g3nYfDXMDPnZ+Lhi0v4aB4fVbz+6GicekgDUJYhC5iOeTYzzIL9VPf8k1OoE?= =?us-ascii?Q?Xby4hdkbwfo+eNOWYTi7qC36ynPHoyT/S59buklBa4rZImD4X8PVD83VgfRe?= =?us-ascii?Q?BLXH+IOuYJdRtzYuiQo+Wx6x6wBVudva8GHJRlpqXFUu81+/plJS1amZ5Y/O?= =?us-ascii?Q?SKn55gLklJ7Krpn1nwNE/ccWg2f8gncoN7RTwTCIVa4BJJqKTrZy4VyUrDGt?= =?us-ascii?Q?zRapsHgjmllFkUWeak808CAbFwiw/KDA+MlZqtpq4yOON+4Eis2OOQXAD+Mt?= =?us-ascii?Q?y/8VoA0X9vevcZaszltgCTtoLmuN/QXhuvAor1rv6L8YeTIUmt3O/FC3L10L?= =?us-ascii?Q?V1gyG8S1Vlh99DxaiDuf0aepLZy94gUEXYFzgGi/d0FbkeycGG649pEfg31X?= =?us-ascii?Q?x13jLeVpPg/Pvk80Q+0/SIRiU/yopvfn7jxIuF6qZZnGzwTexo6nayM6Z9zU?= =?us-ascii?Q?soPbsLODh3VisID1o4A3vHrah3wsb7tdvkRhva4OKoV569wAh6Uc/Koux3v2?= =?us-ascii?Q?CNwMKaoJpbC3r/QEjUISCtaFj6tCGnLXqnUnoy+sua3Q1zCTJziVc+/lM91t?= =?us-ascii?Q?8araG3Aijs/bSY/HdsRAkX/I3Jjcsk4DjpjBW7CIiOfUzrJndS/ExLNTN6H8?= =?us-ascii?Q?Co64c8Aa6ICQp3Omndwf8OAjm1RsWIyqE45L8ckdrVtb1BPMUgZvsaaDKLZ/?= =?us-ascii?Q?mDN/VMchmgLQhkgE8ljEv4sGyRX1Y9ejdkL7H9WwkY5YIZu0Atbhr6guixga?= =?us-ascii?Q?2udfDxvi1JxIqb1T5iNaUZzUl6VcYW3rxC8OlddI7wZdwhvoAxBOA2cgt7c/?= =?us-ascii?Q?NHJpL+REJuX/JGG49lQW1vZk91BSX25bHz+U17uJjRtZRGP5SgX49EO++WvL?= =?us-ascii?Q?gCmfZsLwVC0aHQmN+rYleh4c1HMrIJdYojPP7MZZEsDxUmD3zD1hkq8E4zIS?= =?us-ascii?Q?BoplK9S/eC+dlRv7gVxElz/0c4RapcVj10DSxq/A/KSkDXfpj5HbnFNFNOQd?= =?us-ascii?Q?whTheUJjWtyAbFRhTioB6z+vcB8tvYZjmJA/LEjyZqcN5DD7Bs+mvAKvrktV?= =?us-ascii?Q?/7t4hx7PvjYucUPoio8=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: PH0PR18MB4672.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7d9f559e-550b-4646-9505-08dbba913b9f X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2023 10:55:13.5792 (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: L4BM2VBs4oTbmrjCtsZ23GPPxrsg2JpNGoLUIU787NVHkeUiPKdesdGBoeeYj07EVbVcQ4D72+bLp11gGXhg7A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR18MB5405 X-Proofpoint-GUID: tvFWbnzXOi6KySCFEI5l7CZOf9vmZvCE X-Proofpoint-ORIG-GUID: tvFWbnzXOi6KySCFEI5l7CZOf9vmZvCE X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.980,Hydra:6.0.601,FMLib:17.11.176.26 definitions=2023-09-21_08,2023-09-20_01,2023-05-22_02 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 Hi Harry, Please see inline. Thanks, Anoob > -----Original Message----- > From: Van Haaren, Harry > Sent: Thursday, September 21, 2023 2:09 PM > To: Anoob Joseph > Cc: Hemant Agrawal ; dev@dpdk.org; Matz, > Olivier ; Vidya Sagar Velumuri > ; Thomas Monjalon ; > Akhil Goyal ; Jerin Jacob Kollanukkaran > ; Konstantin Ananyev > > Subject: [EXT] RE: [RFC PATCH 2/3] security: add TLS record processing >=20 > External Email >=20 > ---------------------------------------------------------------------- > > -----Original Message----- > > From: Anoob Joseph > > Sent: Wednesday, September 20, 2023 12:52 PM > > To: Van Haaren, Harry > > Cc: Hemant Agrawal ; dev@dpdk.org; Matz, > > Olivier ; Vidya Sagar Velumuri > > ; Thomas Monjalon ; > Akhil > > Goyal ; Jerin Jacob Kollanukkaran > > ; Konstantin Ananyev > > > > Subject: RE: [RFC PATCH 2/3] security: add TLS record processing > > > > Hi Harry, > > > > Thanks for the review. Please see inline. > > > > Thanks, > > Anoob > > > > > -----Original Message----- > > > From: Van Haaren, Harry > > > Sent: Wednesday, September 20, 2023 2:53 PM > > > To: Anoob Joseph ; Thomas Monjalon > > > ; Akhil Goyal ; Jerin Jacob > > > Kollanukkaran ; Konstantin Ananyev > > > > > > Cc: Hemant Agrawal ; dev@dpdk.org; Matz, > > > Olivier ; Vidya Sagar Velumuri > > > > > > Subject: [EXT] RE: [RFC PATCH 2/3] security: add TLS record > > > processing > > > > > > External Email > > > > > > -------------------------------------------------------------------- > > > -- > > > > -----Original Message----- > > > > From: Anoob Joseph > > > > Sent: Friday, August 11, 2023 8:17 AM > > > > To: Thomas Monjalon ; Akhil Goyal > > > > ; Jerin Jacob ; Konstantin > > > > Ananyev > > > > Cc: Hemant Agrawal ; dev@dpdk.org; > Matz, > > > > Olivier ; Vidya Sagar Velumuri > > > > > > > > Subject: [RFC PATCH 2/3] security: add TLS record processing > > > > > > > > Add Transport Layer Security (TLS) and Datagram Transport Layer > > > > Security (DTLS). The protocols provide communications privacy for > > > > L4 protocols such as TCP & UDP. > > > > > > > > TLS (and DTLS) protocol is composed of two layers, 1. TLS Record > > > > Protocol 2. TLS Handshake Protocol > > > > > > > > While TLS Handshake Protocol helps in establishing security > > > > parameters by which client and server can communicate, TLS Record > > > > Protocol provides the connection security. TLS Record Protocol > > > > leverages symmetric cryptographic operations such as data > > > > encryption and authentication for providing security to the > communications. > > > > > > > > Cryptodevs that are capable of offloading TLS Record Protocol may > > > > perform other operations like IV generation, header insertion, > > > > atomic sequence number updates and anti-replay window check in > > > > addition to cryptographic transformations. > > > > > > > > The support is added for TLS 1.2, TLS 1.3 and DTLS 1.2. > > > > > > From the code below, my understanding is that *ONLY* the record > > > layer is being added/supported? The difference is described well > > > above, but the intended support added is not clearly defined. > > > > > > Suggest reword the last line to clarify: > > > "Support for TLS record protocol is added for TLS 1.2, TLS 1.3 and DT= LS > 1.2." > > > > [Anoob] Indeed. Will reword as suggested. >=20 > Thanks. >=20 > > > > Signed-off-by: Akhil Goyal > > > > Signed-off-by: Anoob Joseph > > > > Signed-off-by: Vidya Sagar Velumuri > > > > --- > > > > doc/guides/prog_guide/rte_security.rst | 58 +++++++++++++ > > > > lib/security/rte_security.c | 4 + > > > > lib/security/rte_security.h | 110 +++++++++++++++++++++= ++++ > > > > 3 files changed, 172 insertions(+) > > > > > > > > diff --git a/doc/guides/prog_guide/rte_security.rst > > > > b/doc/guides/prog_guide/rte_security.rst > > > > index 7418e35c1b..7716d7239f 100644 > > > > --- a/doc/guides/prog_guide/rte_security.rst > > > > +++ b/doc/guides/prog_guide/rte_security.rst > > > > @@ -399,6 +399,64 @@ The API ``rte_security_macsec_sc_create`` > > > > returns a handle for SC, and this handle is set in > > > > ``rte_security_macsec_xform`` to create a MACsec session using > > > > ``rte_security_session_create``. > > > > > > > > +TLS-Record Protocol > > > > +~~~~~~~~~~~~~~~~~~~ > > > > + > > > > +The Transport Layer Protocol provides communications security > > > > +over the > > > > Internet. The protocol > > > > +allows client/server applications to communicate in a way that is > > > > +designed to > > > > prevent eavesdropping, > > > > +tampering, or message forgery. > > > > + > > > > +TLS protocol is composed of two layers: the TLS Record Protocol > > > > +and the TLS > > > > Handshake Protocol. At > > > > +the lowest level, layered on top of some reliable transport > > > > +protocol (e.g., TCP), > > > > is the TLS Record > > > > +Protocol. The TLS Record Protocol provides connection security > > > > +that has two > > > > basic properties: > > > > + > > > > + - The connection is private. Symmetric cryptography is used f= or data > > > > + encryption (e.g., AES, DES, etc.). The keys for this > > > > + symmetric > > > encryption > > > > + are generated uniquely for each connection and are based on = a > secret > > > > + negotiated by another protocol (such as the TLS Handshake > Protocol). > > > The > > > > + Record Protocol can also be used without encryption. > > > > + > > > > + - The connection is reliable. Message transport includes a me= ssage > > > > + integrity check using a keyed MAC. Secure hash functions (e= .g., > > > > + SHA-1, etc.) are used for MAC computations. The Record Prot= ocol > > > > + can operate without a MAC, but is generally only used in thi= s mode > > > > + while another protocol is using the Record Protocol as a tra= nsport > > > > + for negotiating security parameters. > > > > + > > > > +.. code-block:: c > > > > > > The code block below isn't C? Is there a better code block type for > > > a text diagram? > > > > [Anoob] Valid point. I was just following the general scheme followed i= n > this file. > > May be, I'll introduce a .svg image for newly added code. >=20 > This was a nit-pick that perhaps "code-block:: text-diagram" or so exists= . > No need to make a .svg in my opinion, the text-diagrams are clear. [Anoob] Thanks for the confirmation. I do not think "code-block:: text-diag= ram" exists. Anyway, I'll improve the diagrams to make the padding etc more= clear. >=20 >=20 > > > > + Record Write Record Read > > > > + ------------ ----------- > > > > + > > > > + TLSPlaintext TLSCiphertext > > > > + | | > > > > + ~ ~ > > > > + | | > > > > + V V > > > > + +---------|----------+ +----------|---------+ > > > > + | Seq. no generation | | Seq. no generation | > > > > + +---------|----------+ +----------|---------+ > > > > + | | > > > > + +---------|----------+ +----------|---------+ > > > > + | Header insertion | | Decryption & | > > > > + +---------|----------+ | MAC verification | > > > > + | +----------|---------+ > > > > + +---------|----------+ | > > > > + | MAC generation & | +----------|---------+ > > > > + | Encryption | | TLS Header removal | > > > > + +---------|----------+ +----------|---------+ > > > > + | | > > > > + ~ ~ > > > > + | | > > > > + V V > > > > + TLSCiphertext TLSPlaintext > > > > + > > > > +Supported Versions > > > > +^^^^^^^^^^^^^^^^^^ > > > > + > > > > +* TLS 1.2 > > > > +* TLS 1.3 > > > > +* DTLS 1.2 > > > > > > > > Device Features and Capabilities > > > > --------------------------------- diff --git > > > > a/lib/security/rte_security.c b/lib/security/rte_security.c index > > > > c4d64bb8e9..bd7b026547 100644 > > > > --- a/lib/security/rte_security.c > > > > +++ b/lib/security/rte_security.c > > > > @@ -282,6 +282,10 @@ rte_security_capability_get(struct > > > > rte_security_ctx *instance, > > > > if (capability->docsis.direction =3D=3D > > > > idx->docsis.direction) > > > > return capability; > > > > + } else if (idx->protocol =3D=3D > > > > RTE_SECURITY_PROTOCOL_TLS_RECORD) { > > > > + if (capability->tls_record.ver =3D=3D idx- > > > > >tls_record.ver && > > > > + capability->tls_record.type =3D=3D idx- > > > > >tls_record.type) > > > > + return capability; > > > > } > > > > } > > > > } > > > > diff --git a/lib/security/rte_security.h > > > > b/lib/security/rte_security.h index 3b2df526ba..b9d064ed84 100644 > > > > --- a/lib/security/rte_security.h > > > > +++ b/lib/security/rte_security.h > > > > @@ -620,6 +620,99 @@ struct rte_security_docsis_xform { > > > > /**< DOCSIS direction */ > > > > }; > > > > > > > > +/** Salt len to be used with AEAD algos in TLS 1.2 */ #define > > > > +RTE_SECURITY_TLS_1_2_SALT_LEN 4 > > > > +/** Salt len to be used with AEAD algos in TLS 1.3 */ #define > > > > +RTE_SECURITY_TLS_1_3_SALT_LEN 12 > > > > +/** Salt len to be used with AEAD algos in DTLS 1.2 */ #define > > > > +RTE_SECURITY_DTLS_1_2_SALT_LEN 4 > > > > + > > > > +/** TLS version */ > > > > +enum rte_security_tls_version { > > > > + RTE_SECURITY_VERSION_TLS_1_2, /**< TLS 1.2 */ > > > > + RTE_SECURITY_VERSION_TLS_1_3, /**< TLS 1.3 */ > > > > + RTE_SECURITY_VERSION_DTLS_1_2, /**< DTLS 1.2 */ > > > > +}; > > > > + > > > > +/** TLS session type */ > > > > +enum rte_security_tls_sess_type { > > > > + /** Record read session > > > > + * - Decrypt & digest verification. > > > > + */ > > > > + RTE_SECURITY_TLS_SESS_TYPE_READ, > > > > + /** Record write session > > > > + * - Encrypt & digest generation. > > > > + */ > > > > + RTE_SECURITY_TLS_SESS_TYPE_WRITE, }; > > > > + > > > > +/** > > > > + * Configure soft and hard lifetime of a TLS record session > > > > + * > > > > + * Lifetime of a TLS record session would specify the maximum > > > > +number of > > > > packets that can be > > > > + * processed. TLS record processing operations would start > > > > + failing once hard > > > > limit is reached. > > > > + * > > > > + * Soft limits can be specified to generate notification when the > > > > + TLS record > > > > session is approaching > > > > + * hard limits for lifetime. This would result in a warning > > > > + returned in > > > > ``rte_crypto_op.aux_flags``. > > > > > > Can we define "a warning" better? Perhaps an example of a soft-limit > > > and hard-limit, what the user can check aux_flags for, to identify? > > > Or link to the appropriate part of the crypto_op.aux_flags documentat= ion > to help the user. > > > > > > > [Anoob] The concept of lifetime is present in most protocols. Idea is > > to limit the max number of operations performed with a session. Soft > > expiry notification is to help application prepare for an expiry and > > setup a new session before the current one expires. >=20 > Understood, yes. >=20 > > The idea was borrowed from IPsec which has the > > 'RTE_CRYPTO_OP_AUX_FLAGS_IPSEC_SOFT_EXPIRY' flag defined. But I > > realize, it should be better defined. I can rename the flag to > > 'RTE_CRYPTO_OP_AUX_FLAGS_SEC_SOFT_EXPIRY' to avoid redefining > same > > flag for each security offload. Do you agree to this suggestion? > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__elixir.bootlin.c= o > > m_dpdk_latest_source_lib_cryptodev_rte-5Fcrypto.h- > 23L67&d=3DDwIFAg&c=3DnKj > > Wec2b6R0mOyPaz7xtfQ&r=3DjPfB8rwwviRSxyLWs2n6B- > WYLn1v9SyTMrT5EQqh2TU&m=3DF6 > > > WuwwuvXG0eJ1IWAMFgcXlMdQwKFDx6C1qsQgSaDa2XGr3PZ6LEDtSw0OeC > DstG&s=3D0iO8Y > > sr0f4cnE8ihg40sZfEEZfPzEXvJBvcNcyOdS98&e=3D >=20 > So we cannot "just rename" the flag, its an API break. It likely is possi= ble to > add an additional #define with the same value as IPSEC_SOFT_EXPIRY, and > call it SEC_SOFT_EXPIRY. > Is that the best/most descriptive name? SYM_ALG_SOFT_EXPIRY? I'm not > sure here, input welcomed. >=20 > Perhaps we can improve the doc-string there, to explain what it means a b= it > more verbosely. [Anoob] Agreed. Let me try to improve these aspects in next version. We can= revisit this topic after that and see if we are able to reach a conclusion= . >=20 > > Do note that once hard expiry is hit, the operation would fail. > > Expectation is, cryptodev would return 'RTE_CRYPTO_OP_STATUS_ERROR' > in case of errors. >=20 > That is good. >=20 >=20 > > > > + */ > > > > +struct rte_security_tls_record_lifetime { > > > > + /** Soft expiry limit in number of packets */ > > > > + uint64_t packets_soft_limit; > > > > + /** Hard expiry limit in number of packets */ > > > > + uint64_t packets_hard_limit; > > > > +}; > > > > + > > > > +/** > > > > + * TLS record protocol session configuration. > > > > + * > > > > + * This structure contains data required to create a TLS record > > > > +security > > > session. > > > > + */ > > > > +struct rte_security_tls_record_xform { > > > > + /** TLS record version. */ > > > > + enum rte_security_tls_version ver; > > > > + /** TLS record session type. */ > > > > + enum rte_security_tls_sess_type type; > > > > + /** TLS record session lifetime. */ > > > > + struct rte_security_tls_record_lifetime life; > > > > + union { > > > > + /** TLS 1.2 parameters. */ > > > > + struct { > > > > + /** Starting sequence number. */ > > > > + uint64_t seq_no; > > > > + /** Salt to be used for AEAD algos. */ > > > > + uint8_t salt[RTE_SECURITY_TLS_1_2_SALT_LEN]; > > > > + } tls_1_2; > > > > + > > > > + /** TLS 1.3 parameters. */ > > > > + struct { > > > > + /** Starting sequence number. */ > > > > + uint64_t seq_no; > > > > + /** Salt to be used for AEAD algos. */ > > > > + uint8_t salt[RTE_SECURITY_TLS_1_3_SALT_LEN]; > > > > + /** > > > > + * Minimum payload length (in case of write > > > sessions). > > > > For shorter inputs, > > > > + * the payload would be padded appropriately before > > > > performing crypto > > > > > > Replace "would be" with "must be"? And who must do this step, is it > > > the application? > > > > [Anoob] Padding is performed by the PMD/cryptodev device. I'll change > > "would be" to "will be". Would that address your concern? >=20 > I suppose my concern is "is it clear to PMD authors that they must implem= ent > X in their PMD", and to ensure we (DPDK community) do our best to clarify > API demands, and to ensure future contributions are of high quality too. >=20 > For example, could we have a security library unit-test that checks the > padding case, to ensure correct & consistent behaviour across different > crypto PMDs? [Anoob] Glad that you brought up that point. For IPsec, we have rather exte= nsive framework which covers all the features that are supported today in r= te_security. Features like soft expiry & hard expiry are tested on platform= s that support the same. As for TLS, we are working on adding unit test fra= mework. It would be part of the next version. >=20 > Same thoughts for SOFT and HARD error variants, (although they might > take... hours?) to execute. > But it is nice to automate-and-test these "corner cases". [Anoob] It won't. Soft expiry can be very low value as well. It is already = covered. Please check. https://elixir.bootlin.com/dpdk/latest/source/app/test/test_cryptodev.c#L10= 272 >=20 > It's not about wording, its about clarity between PMD devs, security libr= ary > devs, and application facing APIs, to ensure that DPDK provides the > most/best help it can to provide correctness. Does that clarify what I'd = like to > see? [Anoob] I understand your concern. My understanding is that for security of= floads (rte_security lib), documentation has complete details of applicatio= n & PMD expectations. If we have missed some features, we can take a re-loo= k at the features and add as required. Other than documentation, do you hav= e any other suggestions in mind? >=20 > For this patchset, could we document a list of "caveats" when implementin= g > PMD functionality for TLS-record security offload, and indicate that: > 1) Padding must be added by the PMD based on security library flags& algo= in > use, not application layer (I know this is demanded by the sym algos anyw= ay, > but let's make it explicit) [Anoob] Agreed. Will update documentation as required. > 2) It is strongly recommended to build unit-tests for _SOFT and _HARD err= or > cases (potentially by "fast forwarding" the internal counters via private= APIs > to avoid hours of enc/decryption) [Anoob] For IPsec, it is already added. For TLS, we have plans to add the s= ame. >=20 > I think that limits scope-impact to this patchset, but is clear for PMD > implementations in future what expectations are. > Thoughts, is that a good way forward? [Anoob] Indeed. Having a very well defined API interface for applications i= s a very positive change. I'm open to more ideas than just updating the doc= umentation. Appreciate your feedback.