From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0068.outbound.protection.outlook.com [104.47.38.68]) by dpdk.org (Postfix) with ESMTP id 2B4B0E5D for ; Fri, 15 Dec 2017 09:30:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XzBXnDDbFX4VfINhENVjVgwAfklLr2uCNMSVKFV0sxo=; b=SVWWLvmh1wcBz93K8n0yGrq9TaHrttI0wshQOuZeswOLSCw1Q60SnKUJnw/6P9fvNETmYJ1XXOJSdK8N8mXxa/yOE6WjkGeER66UaGMYUdEqZldl2F0XDpGF5Sb9PASNK4SlmDkkvX/4Z7/9cbVm40U0qYMx8pqQMHLcATZzDZ0= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Anoob.Joseph@cavium.com; Received: from ajoseph83.caveonetworks.com (115.113.156.2) by CY4PR0701MB3636.namprd07.prod.outlook.com (2603:10b6:910:93::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Fri, 15 Dec 2017 08:30:28 +0000 From: Anoob Joseph To: Akhil Goyal , Declan Doherty , Radu Nicolau , Sergio Gonzalez Monroy Cc: Anoob Joseph , Jerin Jacob , Narayana Prasad , dev@dpdk.org Date: Fri, 15 Dec 2017 08:30:05 +0000 Message-Id: <1513326606-21970-2-git-send-email-anoob.joseph@caviumnetworks.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1513326606-21970-1-git-send-email-anoob.joseph@caviumnetworks.com> References: <1511435969-5887-1-git-send-email-anoob.joseph@caviumnetworks.com> <1513326606-21970-1-git-send-email-anoob.joseph@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [115.113.156.2] X-ClientProxiedBy: CY4PR02CA0018.namprd02.prod.outlook.com (2603:10b6:903:18::28) To CY4PR0701MB3636.namprd07.prod.outlook.com (2603:10b6:910:93::11) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 70ba2c55-2f0b-4120-764d-08d543961a78 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(7168020)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:CY4PR0701MB3636; X-Microsoft-Exchange-Diagnostics: 1; CY4PR0701MB3636; 3:qANDCrsJ6Gu4sYOYBiVt0JHzqP1JM47VQGReEos00poLnhIGQoGNuNXebl+gomQLIAb5Bt8hJGVreREBRxfJrAEnStYp5FaDWPR1Wdtku1FTuGJmPmK5MFVfxeqgedVJR5eaNHU/Tj16kwrQJiR/ivXu/KQvVVev/X5yIXpeHG0OY3ttfur+K9JdA85GDgIY3clXJ9JpxQfEvs0WRE/3pIoIuf5jztDEiVkmnrcSXTcx3jtKLzuSy2SZkIGmYN/O; 25:xWeUJgIbMB3KGNNfrd+sv5h3A8puf9RW0aMxBVqfxy5+eoyCMxlodpVySc+ozuLfNr0YUCfssfcaeYVSnQbass1jyNGyPPBKz7jczvI6lNZkT5dEoyuh1BPLkrJw9eOy4FHAY3BC1nzekl1PBNziPAecirhVEuZdZItEo+aa5MhEJbzYwj//tV5knIEGpnUAu0bWNBJbli7b97p2DtdB68Ral0opIAFNeFId4vJfOA9jxyF6iftckHl4ueG48YxddgMyJ66frBBA1pXt70DyuCgwUw1HLR4b2Y0ZkAFG21KqF71dCXkWhgjppi7RQV1p9vDfDBh84lAbdndiwLpXGg==; 31:4laXS+AHa0JWXJJdia0eZ4FjhCobOydPs9/3a7Z67STPuJ8ah2y8j9OjUY0/KNWxlwEnLW53LEINpP/zW75c06L3A9aQm5f3RQP5H3JIsU9rSFEYh4rnGqp9zhxQN5BeNsPMg5xn1Sqy6C+ua/WNlP6sCjppSr0Mb+JkfZsCGsirPTB/T4U3n9ixehkVMv/Gi8SAh/UP2mzpde5IUMED2fB25rv+84uOPQgvL8H1YaA= X-MS-TrafficTypeDiagnostic: CY4PR0701MB3636: X-Microsoft-Exchange-Diagnostics: 1; CY4PR0701MB3636; 20:REUEcSsEGXCkt+6BAd7oBChN7DaPuzT9zH1MOI7aqY9xfd3cdV1UtEvUvbHM0nfVKdTnfs8lGaBl+cNm1/DEV1vE1VkrxbNm6p23RiDYPdUqcGb8QSW/5nVtQJrkIlSuj4zVAz0Rk0FJPUm+w6CX2jOD93PlZ5UfpmT+HXNJjuICMIwrzwijYScZWmppS3pidFnyq4iEtb0KYND1UoUe1XzI0AZFPcDQuhf5AwO465fVsM6hyUlkq2rA42ffzGq5DlX5lMMEKUlliIO4LSr30hc8KyZSvE8udeUfaqzX++s+9kt45oulQpFwpq3zZST7irZXiHD+NP9+DGCASB987bnAcTr96gB+JfsBq3YLSPJPa9gx9gXk1O2s3JAB9foYguCCBwY5TY3zDbu3fldadZW/Zg4gLbwUKIYCe5XueVBQv+r4DdaSlRJ2m1nTOrKJ58InZYFzIML6yvZ/iOuu9zSvWcaLSpGFHOaIorwXnJKDaG7bnF2RNW2p/XuLUo1lxB9fMiWfOJZ+zchohHrhqtnjiDEeuFHyVO1l2LQI75XRy0AydkrTr6KRmyNkuAL7OZbNrr+CAYKGm4tlE+1aLV4JxykQB6zHjJr2QNnUmdo=; 4:Kzo4gj0I6WU7ZLpsoKPO0K+ZOG6bqcsl/iBzdhMs23RxrHM/ByFBTMbFfWM2wxke5LoArPUFOu4xW81t8JEpOlhXBtv6qugXSz4HzaWF8mKW981IkwNsOMucJjeScFUGDQVvBE/5iYlyXDyAQxFDY/BPMEw4ANzGfrceSFOTefVs709bRMTIrM3IjzR3r9PGgI+vJgO8i9AsmLqQb3lfRbmAllG7osc4f2oeAJYlqcqqCkr0SIdqWYeTXww++xeSGcQkrZQon7PqgJ3moEPBihyXF1nkLXiBsYg6c8wQ1XUXNkYOAv0e8mYtq3e+Mnaq X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(3231023)(10201501046)(3002001)(6041248)(20161123558100)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(6072148)(201708071742011); SRVR:CY4PR0701MB3636; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR0701MB3636; X-Forefront-PRVS: 05220145DE X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(366004)(39860400002)(199004)(189003)(50226002)(6512007)(6486002)(66066001)(42882006)(2950100002)(47776003)(6116002)(8936002)(68736007)(3846002)(72206003)(76176011)(53416004)(59450400001)(6666003)(16586007)(16526018)(110136005)(478600001)(8656006)(51416003)(50466002)(52116002)(48376002)(54906003)(316002)(15650500001)(5890100001)(53936002)(25786009)(4326008)(7736002)(2906002)(305945005)(106356001)(5660300001)(97736004)(69596002)(81156014)(36756003)(6506007)(386003)(55236004)(81166006)(8676002)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR0701MB3636; H:ajoseph83.caveonetworks.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR0701MB3636; 23:N7vTTD76HsaIMbJB7I9pfPcLSJvB48ymhw5eyLc?= =?us-ascii?Q?hivW+9iSq1yuHdTjIidC2j6Es4pLVuOL7z0sjJXehLro2qFUuuBf+vDrVIEO?= =?us-ascii?Q?gFHM+T9+Th6cU7vcC7xHyaGfKRgfKZCGc1R9FxHTOuLypWoPFTvQVW+imu0c?= =?us-ascii?Q?k8y8pCgczi3Kz0jo1wVEolPW+cuOw0D/Jrgo1hB1VC+N6aNktJdOB/ry4hMe?= =?us-ascii?Q?5P8vnwW/pXd7KuhNITjVTPGziRTyhhMsgrp5WxVELV6gtAqVPjPOPdF7Calm?= =?us-ascii?Q?/ITRQAn2zHPOcUZl+wmvFfr2Mt2Tk63NDgcJEIfm59lWAO0D9nPzW5BjgvKp?= =?us-ascii?Q?r/UMHgh7fJleJQqi75TiAoTW6RN1NXaY3Dh1WOa7Y3AqE90hJvHSvUmUstHv?= =?us-ascii?Q?6Zz66DGjQ8XJ/edJgAnDnWprkrHPM6SIGlHig/MnowL3BW+Pl55q3n+EzVfF?= =?us-ascii?Q?VQ189mDTUP2+HrSHs78Rm9tdWuuLd+B4i4cMqEVGu33fDxbHeA20eJ4h1k96?= =?us-ascii?Q?v1c8CgcjWWYLvwGmWVT1FlV4G9P/MUwW964rxPk0d+K+Fqi2Sr1p55ImmVfc?= =?us-ascii?Q?seYQy9W7o91gQzoTT1hnL0N42Iv6sr8L9ZVHJXp+NLkEuug0e/C5w++oR49U?= =?us-ascii?Q?Wq7uOh10fNtWMFJw1VDoafCG2yH0aM5gy2/lwEYEy50FXLJEngLbqRPUwTMD?= =?us-ascii?Q?3Tt9UTd8iAcfzBXlbqL2fU8LrYx/Tvwu3WvhIlZ14wOYqEC/hF86GIZLMm7K?= =?us-ascii?Q?6ESK8VWwc4VzTo+iFWHRDfCP5l+bg1pH8YJ244Sa4fBucZ5dsGOYVzfYXB9i?= =?us-ascii?Q?fHhdJ4EGuSZplUAl6sEwAfQESXSFYEz9PWgpFM67f5mQWa7IRyLEbLMQZl72?= =?us-ascii?Q?JHqyR7JemSB5RmR7GdOo+JXyk/vB7T1VTN9bCTfBrfeg50OEIcpDIOHSys54?= =?us-ascii?Q?6sWQNL2QYpnLOQRe3HKSyQOzusDwaHJagqakJToU5IqI4Zt8+N6IA+Y6l90y?= =?us-ascii?Q?g7UTVyIjG0zY2nW9JKnGh6DH/ZfqGAsR5DXLHVPb0MEwu2Y72m1++zzHYmBi?= =?us-ascii?Q?TA8LhPVKVJFYFLrJhIgiqpKfW4cPKi4WyfAz58FI2TnlbvA3jxkm586i2kGb?= =?us-ascii?Q?qyU1P//scaGlHEe+ByUEIz55tMHxeut8TAEPlKuV1fU/OMoWycWq34wBXcAq?= =?us-ascii?Q?jEWv8+w/Xy2OR5rt80YR75Ou1eJJY6Lx38se+4y48BOboPc3vCd5m8ihyAF4?= =?us-ascii?Q?rlMd3883k9Vs0S8aID1M=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR0701MB3636; 6:7ZdQEHOm6rHth53rfXF/690Js+uNAl/I255zfaFDeVslq5LF/IX8UgFEyuAKIBPRTyYgPkG15h6OGv6USaSw8N2cq85uCsbmk+lfaIj0A8zxYVsEBnQDFuCBzz2CJM4kHdxIaeVuxYg565XYoJFuz1TnfBNzqN0Mdy/FaOpQ2JQsl6SAFzI/KBleyjv1QWwxpde5jJOyiZ+5MAe/nYq1e5kqev7Lz9WUcli0q/3o+ee06K1dbRqoHnUiP2WgCE61E/2wKxldD2KMZfFHHaXMr3hPy7tFOSk3UlE2VyRVoInix/zJ6tipOI3zge6rgYL78O0v1gOpc1EIb2dXQOeJpQzFqkGB3oOty0k7T4nwJyI=; 5:Rct1W4sd+DuGMqWsNpXiEMIGohMuqJgn0JFj9UAkZXldz3b2+N5ugQk3bUT4Q8ImYCznhZcBrryEF7/F9f+a/Bh8SZjVsxRC8tG+tVSXsuOBIhkQtJCOGHRVlRo7fJFEa7PZPNRGpT6R9vKd0hGJhp5/KCYK2c6Dmf31wOSsKfU=; 24:rxeyholvv1vGYknWDZpjmsdR1YoPmvMGn200nk2lLg1o6C9Q3iBk/SEigqYrOlVchSSJlineu8YdNDL01a2v3MyurpHZjge5F/G4POjidyU=; 7:6/u1VFoVsNe0XHFkXk3hmJ0yqyHGBZb7Ibw02DkvJW4KnFnFwVhfudnMRuqJ1dMKTAND/6yX/0PohLPRIhmhwcwpz4yGp5aR10mdIrpHUmGSFNG8oVRZIORpMOlBbrcl9Xava54xbPBsTn5xS6wxF7H6hJKf3/41sqN22gaVnRZnleQ00q4i9tzAeL+gQ5gRtNqR7IKLbqxnochKeFm7CSszQ4OmH2ELd7ukqzHgYrDwULOelqugEVXnijyKIqpW SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Dec 2017 08:30:28.6519 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 70ba2c55-2f0b-4120-764d-08d543961a78 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0701MB3636 Subject: [dpdk-dev] [PATCH v4 1/2] lib/security: add support for get userdata 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: , X-List-Received-Date: Fri, 15 Dec 2017 08:30:33 -0000 In case of inline protocol processed ingress traffic, the packet may not have enough information to determine the security parameters with which the packet was processed. In such cases, application could get metadata from the packet which could be used to identify the security parameters with which the packet was processed. Application could register "userdata" with the security session, and this could be retrieved from the metadata of inline processed packets. The metadata returned by "rte_security_get_pkt_metadata()" will be device specific. Also the driver is expected to return the application registered "userdata" as is, without any modifications. Signed-off-by: Anoob Joseph --- v4: * Documented the usage of rte_mbuf.udata64 field by security library * Removed (rte_security_get_pkt_metadata() API as the udata64 field itself will have device-specific metadata, and could be directly used v3: * Replaced 64 bit metadata in conf with (void *)userdata * The API(rte_security_get_pkt_metadata) would return void * instead of uint64_t v2: * Replaced get_session and get_cookie APIs with get_pkt_metadata API doc/guides/prog_guide/rte_security.rst | 22 +++++++++++++++++++++- lib/librte_security/rte_security.c | 12 ++++++++++++ lib/librte_security/rte_security.h | 20 ++++++++++++++++++++ lib/librte_security/rte_security_driver.h | 18 ++++++++++++++++++ lib/librte_security/rte_security_version.map | 1 + 5 files changed, 72 insertions(+), 1 deletion(-) diff --git a/doc/guides/prog_guide/rte_security.rst b/doc/guides/prog_guide/rte_security.rst index 71be036..6768ebe 100644 --- a/doc/guides/prog_guide/rte_security.rst +++ b/doc/guides/prog_guide/rte_security.rst @@ -148,7 +148,9 @@ packet. e.g. in the case of IPSec, the IPSec tunnel headers (if any), ESP/AH headers will be removed from the packet and the received packet will contains the decrypted packet only. The driver Rx path checks the descriptors and based on the crypto status sets additional flags in -``rte_mbuf.ol_flags`` field. +``rte_mbuf.ol_flags`` field. The driver would also set device-specific +metadata in ``rte_mbuf.udata64`` field. This will allow the application +to identify the security processing done on the packet. .. note:: @@ -421,6 +423,22 @@ For Inline Crypto and Inline protocol offload, device specific defined metadata updated in the mbuf using ``rte_security_set_pkt_metadata()`` if ``DEV_TX_OFFLOAD_SEC_NEED_MDATA`` is set. +For inline protocol offloaded ingress traffic, the application can register a +pointer, ``userdata`` , in the security session. When the packet is received, +``rte_security_get_userdata()`` would return the userdata registered for the +security session which processed the packet. + +.. note:: + + In case of inline processed packets, ``rte_mbuf.udata64`` field would be + used by the driver to relay information on the security processing + associated with the packet. In ingress, the driver would set this in Rx + path while in egress, ``rte_security_set_pkt_metadata()`` would perform a + similar operation. The application is expected not to modify the field + when it has relevant info. For ingress, this device-specific 64 bit value + is required to derive other information (like userdata), required for + identifying the security processing done on the packet. + Security session configuration ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -440,6 +458,8 @@ Security Session configuration structure is defined as ``rte_security_session_co /**< Configuration parameters for security session */ struct rte_crypto_sym_xform *crypto_xform; /**< Security Session Crypto Transformations */ + void *userdata; + /**< Application specific userdata to be saved with session */ }; The configuration structure reuses the ``rte_crypto_sym_xform`` struct for crypto related diff --git a/lib/librte_security/rte_security.c b/lib/librte_security/rte_security.c index 1227fca..5805051 100644 --- a/lib/librte_security/rte_security.c +++ b/lib/librte_security/rte_security.c @@ -108,6 +108,18 @@ rte_security_set_pkt_metadata(struct rte_security_ctx *instance, sess, m, params); } +void * +rte_security_get_userdata(struct rte_security_ctx *instance, uint64_t md) +{ + void *userdata = NULL; + + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_userdata, NULL); + if (instance->ops->get_userdata(instance->device, md, &userdata)) + return NULL; + + return userdata; +} + const struct rte_security_capability * rte_security_capabilities_get(struct rte_security_ctx *instance) { diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h index 653929b..a34cbba 100644 --- a/lib/librte_security/rte_security.h +++ b/lib/librte_security/rte_security.h @@ -274,6 +274,8 @@ struct rte_security_session_conf { /**< Configuration parameters for security session */ struct rte_crypto_sym_xform *crypto_xform; /**< Security Session Crypto Transformations */ + void *userdata; + /**< Application specific userdata to be saved with session */ }; struct rte_security_session { @@ -346,6 +348,24 @@ rte_security_set_pkt_metadata(struct rte_security_ctx *instance, struct rte_mbuf *mb, void *params); /** + * Get userdata associated with the security session which processed the + * packet. This userdata would be registered while creating the session, and + * application can use this to identify the SA etc. Device-specific metadata + * in the mbuf would be used for this. + * + * This is valid only for inline processed ingress packets. + * + * @param instance security instance + * @param md device-specific metadata set in mbuf + * + * @return + * - On success, userdata + * - On failure, NULL + */ +void * +rte_security_get_userdata(struct rte_security_ctx *instance, uint64_t md); + +/** * Attach a session to a symmetric crypto operation * * @param sym_op crypto operation diff --git a/lib/librte_security/rte_security_driver.h b/lib/librte_security/rte_security_driver.h index 997fbe7..4e93362 100644 --- a/lib/librte_security/rte_security_driver.h +++ b/lib/librte_security/rte_security_driver.h @@ -122,6 +122,22 @@ typedef int (*security_set_pkt_metadata_t)(void *device, void *params); /** + * Get application specific userdata associated with the security session which + * processed the packet. This would be retrieved using the metadata obtained + * from packet. + * + * @param device Crypto/eth device pointer + * @param md Metadata + * @param userdata Pointer to receive userdata + * + * @return + * - Returns 0 if userdata is retrieved successfully. + * - Returns -ve value for errors. + */ +typedef int (*security_get_userdata_t)(void *device, + uint64_t md, void **userdata); + +/** * Get security capabilities of the device. * * @param device crypto/eth device pointer @@ -145,6 +161,8 @@ struct rte_security_ops { /**< Clear a security sessions private data. */ security_set_pkt_metadata_t set_pkt_metadata; /**< Update mbuf metadata. */ + security_get_userdata_t get_userdata; + /**< Get userdata associated with session which processed the packet. */ security_capabilities_get_t capabilities_get; /**< Get security capabilities. */ }; diff --git a/lib/librte_security/rte_security_version.map b/lib/librte_security/rte_security_version.map index e12c04b..87f35d7 100644 --- a/lib/librte_security/rte_security_version.map +++ b/lib/librte_security/rte_security_version.map @@ -9,6 +9,7 @@ EXPERIMENTAL { rte_security_session_stats_get; rte_security_session_update; rte_security_set_pkt_metadata; + rte_security_get_userdata; local: *; }; -- 2.7.4