From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0089.outbound.protection.outlook.com [104.47.40.89]) by dpdk.org (Postfix) with ESMTP id EF3532B83 for ; Fri, 24 Nov 2017 13:03:53 +0100 (CET) Received: from MWHPR03CA0020.namprd03.prod.outlook.com (10.175.133.158) by CY1PR03MB2364.namprd03.prod.outlook.com (10.166.207.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Fri, 24 Nov 2017 12:03:52 +0000 Received: from BY2FFO11FD038.protection.gbl (2a01:111:f400:7c0c::139) by MWHPR03CA0020.outlook.office365.com (2603:10b6:300:117::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.260.4 via Frontend Transport; Fri, 24 Nov 2017 12:03:52 +0000 Authentication-Results: spf=fail (sender IP is 192.88.168.50) smtp.mailfrom=nxp.com; Received-SPF: Fail (protection.outlook.com: domain of nxp.com does not designate 192.88.168.50 as permitted sender) receiver=protection.outlook.com; client-ip=192.88.168.50; helo=tx30smr01.am.freescale.net; Received: from tx30smr01.am.freescale.net (192.88.168.50) by BY2FFO11FD038.mail.protection.outlook.com (10.1.14.223) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.20.218.12 via Frontend Transport; Fri, 24 Nov 2017 12:03:52 +0000 Received: from [10.232.134.49] ([10.232.134.49]) by tx30smr01.am.freescale.net (8.14.3/8.14.0) with ESMTP id vAOC3mOh004718; Fri, 24 Nov 2017 05:03:49 -0700 To: Radu Nicolau , Anoob Joseph , Declan Doherty , Sergio Gonzalez Monroy CC: Jerin Jacob , Narayana Prasad , References: <1511333716-11955-1-git-send-email-anoob.joseph@caviumnetworks.com> <1511435969-5887-1-git-send-email-anoob.joseph@caviumnetworks.com> <1511435969-5887-2-git-send-email-anoob.joseph@caviumnetworks.com> <414c3491-7a54-09b4-0cde-a21bffaeb1ab@intel.com> <94ae34d4-b34a-22a1-e787-e2dcdffc8575@nxp.com> <63e76b4d-3e6a-bd74-3ad8-72fcacef0fcb@nxp.com> <45060b96-9b19-fe62-7653-5ad734188c93@intel.com> From: Akhil Goyal Message-ID: <7f193513-bfdb-81dc-48b4-ee844928745d@nxp.com> Date: Fri, 24 Nov 2017 17:33:47 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <45060b96-9b19-fe62-7653-5ad734188c93@intel.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Matching-Connectors: 131559986323565611; (91ab9b29-cfa4-454e-5278-08d120cd25b8); () X-Forefront-Antispam-Report: CIP:192.88.168.50; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(336005)(376002)(39380400002)(346002)(39860400002)(2980300002)(1109001)(1110001)(3190300001)(339900001)(199003)(189002)(24454002)(105606002)(106466001)(54356999)(8676002)(50986999)(97736004)(76176999)(77096006)(229853002)(81166006)(31686004)(81156014)(2906002)(356003)(305945005)(53936002)(189998001)(50466002)(2870700001)(67846002)(64126003)(83506002)(4326008)(2950100002)(5660300001)(65826007)(15650500001)(6246003)(104016004)(498600001)(110136005)(54906003)(58126008)(93886005)(33646002)(316002)(53546010)(65956001)(65806001)(68736007)(31696002)(86362001)(85426001)(8936002)(36756003)(23676004)(2486003)(47776003); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR03MB2364; H:tx30smr01.am.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD038; 1:4H7Yv1MAo/erAqwL5qBqrFfKjHpNN2z+OO9miGlqcu9gB+CaN55vo3ihHdoTpoo4w4km/6UjT166ackYKvkT4jQG9qtQwFT+UBEDChtYMf4Ffm8y+42GGzSLttJHFkIo X-MS-PublicTrafficType: Email X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4628075)(201703131517081)(2017052603258); SRVR:CY1PR03MB2364; X-Microsoft-Exchange-Diagnostics: 1; CY1PR03MB2364; 3:hX01zydKhM1EnE9JU8amrRkGhYl1JeXynNZKQK9CZ18p4vRuEdTvb2od26sSKMl7oDlfViSVNaWIm3Om7KlG3+O50nfYaSGZARwDpZgnWgoezrlajCP5+NjQeny/wUVI85wrhIaH5nbztopCbg2cJXl4eYeBengENdp0PxLLRfHW8ImYy8eIB6SE2C+D/gbLMZLAfOKzPOZ/tMDDICpKs4EsqqhTAoTUPl+gUd0ME570HDhxfs/RfyDhVoK8/38ut1nFIE0LwQSP224NEs5Ob+RxCAGJfIy+Ibz09K9Za1OYStwD/g8YDtU1j/hsK1blCYz24SBQVljQAk0RTXJezeJlhXNBD2YS9HTYbaEYbwE=; 25:CBGe0yZxwulAzxNcuRd6Gv8aszC0UwLzuWTWZzCB075KOK6MvObi3lC50Y/z3gwZApzSXcBtgJAyRdZkYbDc+EXYCfITmcfwChwlAb4H65krATIEthxzRD7+QqZ3Ei1G1REGBdOCEHFx7SUuByZPkHhUBhRpqOmy/UwDKffruJLTeeALif+WiMxl10baQs/3aPy53f5idJipHzSQi6MSXBjRmEyljEt0xq1/SwhJEKGkx/4BaP/XYIv2ashg70a4DGmB9ESr85srIm9OawiB1SGoB80RgQFZGXEree6iMqkgEUe0od5byEARVCRwIGWd4aF6u6VKKe8s20Gv+pNpASLoNCaKg6kqp7/onU2c8Aw= X-MS-TrafficTypeDiagnostic: CY1PR03MB2364: X-MS-Office365-Filtering-Correlation-Id: 771ae55b-c928-451d-ac2b-08d533336def X-Microsoft-Exchange-Diagnostics: 1; CY1PR03MB2364; 31:8lFeY16aLJVHKJwMwo8jfsmZ3TSVKC29/Yvs4cWcQEG6YDONntXKyWlL4fNjrlb1oejtKP/pza9DmL8/TcYBhVyaOXQOn0K1Tq/gBpkZQ0q8oVidFIrZvMgw5VhzZVc8LSRM8szbyttdbyLqxjj8eZ/w/8y5niMBkneY3+xRm4aEnrgwG2wqeovqycR5q94d68/quLQvNbQbuOsY5niiPwTBSLBtXUxuUMZdGA0YU64=; 4:rlzf1FJdg2BEm8HSEyczefn5DYebuB7kBIW3HMKUU8HR4QDXhYhxWiYCx+v1ca44FIvl+fP5ANFtTz13CSkER3dUXTWOOfNZn8HX84vjr7rfvxAei4ywniH+RkeWx+wzmbF0VfD3B2IBc0Y0/jN+gHnbfyhN5xePzOFfLTT8P7D1Uw4+kYKrNgokPa4ElA3MuCS5+TvwpiDqT8u3ZeJAMuXyALJ21pghCBscEtu6J+lPpZpKGLH0w0s7BW7H/OuMGVGRM0yC4hVXsLbo+/IRuwrN9x0CnSNHesKSgmGODZKklngwb5mVkA1gWRIuYU0a X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6095135)(2401047)(8121501046)(5005006)(3231022)(10201501046)(93006095)(93001095)(3002001)(6055026)(6096035)(20161123556025)(20161123563025)(20161123565025)(20161123561025)(201703131430075)(201703131433075)(201703131448075)(201703161259150)(201703151042153)(20161123559100)(201708071742011); SRVR:CY1PR03MB2364; BCL:0; PCL:0; RULEID:(100000803101)(100110400095)(400006); SRVR:CY1PR03MB2364; X-Forefront-PRVS: 05015EB482 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjAzTUIyMzY0OzIzOmFaM0pXUGdmaUt0cDNUWjE0VnM0NEdTWHQ3?= =?utf-8?B?QzN3eDBKVEVrRlZqaHlpNXJmeWRzVEpRdE02MEdRT2UwMk5tUEZ3czZtRHVL?= =?utf-8?B?dHJoU3ZrMTR1S1hSdGpOdy9NY2xwWUx1bXhhYUtaa005VC9sYzQrWE9FN0tK?= =?utf-8?B?SCtnSVdEcHVjWERPemhaYWpoUXdkcmtVaWJneUVCRmN6YWsrKy90VXY3TFl2?= =?utf-8?B?UE9iNEd0U0gvMk0yN0RUNUZvSW1jQ253TFVHSlB3V0lGMVlnOGEwc2pqWDda?= =?utf-8?B?Ynk5STJjemcvQ3ZEb1hHYlFublFEOHYrdFBHZkZLQUMvQVdUaThHTVRLWlB4?= =?utf-8?B?bWJmcnB6WjFKZlpacGVYSDd0NCtDaURWdmhBalkrM0ZpNkp6cDRPMW8zWVlF?= =?utf-8?B?U2xYZzhVUzJmWDRvc1dFS2RnckFJc1Z6b0Qzbm5Fdy84NW1iMzRzbmhlNGJ6?= =?utf-8?B?YmI3SjN5MWlTMXB0Y1VVMCt4bG5yVG1nd1RDTnVGc3R4L2YvdU5JdFZRYjdT?= =?utf-8?B?ODllQ1ZCM0FlcW5nbHZSRko1NXhGSmtZWDk0VzdsTmhNc29hYnZveDBMOW5G?= =?utf-8?B?Q1R2NlduL1p5NmVyYkVtVnc4cStPalBFUFNoSUtwRjRRdkRBdjN3V0hFR1B2?= =?utf-8?B?YUhERVM1NVh3VHdueHNuTmZnQ0NUZmFLcEpzcktPbzlqZWZNWVpVdHVnVWV0?= =?utf-8?B?ZUVoVVpCcGRteUkvTm94TmVtUVFqNGgzbmw2Syt0TWYxUFRzOTFVdGpsWXNF?= =?utf-8?B?MjZrR0VFT3g5a1ZFUnNkVUI4aHR0TWVaalAra0FKNURPUG5IcHFLdjJXQ21m?= =?utf-8?B?c29LL3c4bzQ2VkdJbzIwdTBBU08xdzhBOWVsenhUTzVqcVNXeUpyZHhNb25s?= =?utf-8?B?MSt3TjhZWjB3RjF2SFVzbHFQang3SkdDaTJFTGx6bDlSbEp0bTFVRUZmZ0Fu?= =?utf-8?B?Z0ZyclRyQzlDdlBBVldWcy90WTc0QkZBNURnTnpHQ1VBTUZIMDZ4YXllbzFT?= =?utf-8?B?c2xYRlpHOUdJSlhnZ2ZiM0hXRGVmS1F1L05ZRXlUQldUSDdkN3RoQ0drUG5Y?= =?utf-8?B?V2Z1YnJCTFY0YWJKRk1RWC9GUnp4YmVvQnFHOEJLOVdHL0MrRXEvWXRaRlRZ?= =?utf-8?B?K0xlMnQxYzV1UE1BRUh0b1BiZkdCeGk0amlmcWxqTW9aV3VscWZYaE95NzZs?= =?utf-8?B?TFZqREVOZTlSWVBNNmNOWW9aSzRRb2wxQWRBLzdLVmhNSndHRWc4V1I1eXVK?= =?utf-8?B?MDZOU2pDMXZlaEduQ29vdHd4NVAvR1JkYkpvNjVaRFV0WkRkV2J2K0taNWk5?= =?utf-8?B?ZXMwelk2SjQ0cEoxRE5qSHpRYUZpSGlTRml3SjVQYjk1bDVMcDFJdVljZk0y?= =?utf-8?B?TlRSeXdrcFd5K1BMays5WVhhQVloS041UUFPT1lmTXNHNkxHOUkvV0tsQ2Zi?= =?utf-8?B?Rk5HKzJrK0pyVzFOZ2kvS1hUUC9BeGdZQmhVQ1YrNkV0WmpsZE9RaU1uU3Q0?= =?utf-8?B?TEJ2R0V5TVF1djV5SzJsSjJwYnNQN3lpQzFsYmdmdEpLK01SOWg4S2czNkV6?= =?utf-8?B?MEVLRVFvVlB5cVFSdk9Rb1dwb2xSVGhNQm9odGRoVDlUbGY4Q0oyUmRmb0NC?= =?utf-8?B?dkhBbjJ3am9VVFM5TStUcWdOYnV1NkFkRUdoQ2kwWDAwcWw2TzZubXpVUHZp?= =?utf-8?B?dDErNWdmN2dTR3UzcGR4N3RXQ3B6MFJ1UjlKK1JuQU81UnNvZWQxcGNIM3dk?= =?utf-8?B?ZFpHVkxreW9ZdmlCeTU0WWpVYU1pdUgzTEg5S095RzJVM1ZsNFpKTWU4Q21x?= =?utf-8?B?allxcVJwZVNzUzAvUk5ZYnFIS0h0b3VLNUwwYXFZTE8zU0JaOVFtOTVwRG5i?= =?utf-8?B?bkd4TGp2UytrSGdDZGtJWGZ6NFRBWTJEaTE2Tk5EdUg5a2UxbFdzcVlaeEdZ?= =?utf-8?Q?R2Q3Ddq9pHtUreNQ7H3dq/xWC5/8E4=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR03MB2364; 6:pvSp5BmBIhC3g4hnT3WkiiX74833sB0rPafiaOAZJeOQfl8/ViP42a3SKXIITUX6pZ5mUX67cIbfsnACUzWyNf5yDvkSz3+9ytKzuIUl/IzaV/76a+SDogNumVIKe0pSm+Bu7DMNJWtj/zWxwmDfeyfT78ePPY+WkGcFlBsGz2e1k01CQ7qL66dKo5QnWD766t0luJOVJtRgetrwf144FQnWDjGgZpcuXswVGWGHH7ws+TwUQ8tTluZlj5ASTxr278DGD7xprK42DCOijEOCev97azgUFOPSEhx+5JZ/as9TVnuF8dfHaRYxziotvLeE72X6/RmwcNjxx7Juu4uThSTOgueXIZdLogEJxAGMnQs=; 5:i4J6IQJq8cR6AxnILakC3YKNWgEYdgCqjIH/GOG1hIHbSwAOk2zgyHtGUBcZoG9ykmLw7YQd5h7wx8CUArB18F4A9oI1MWmu+Li47jf9X+KNbppQ+QVpW5MVO03l3csnCxiz2XjotzO8jjFQzA4lnaRdmRlDM5yNtz1eW+5FAk4=; 24:XmKi4S+yxp8ysfQXgU3C7fR6DETxUVndkfjm3VjcH8FzV5pH9ltRUhG/ekXSttGTHbimjHuyu1ZOzL5UulV+HVzwuyobdFeyfeMb/aG+jiU=; 7:I6FMtzs3z8bgpmesXVk2CKS6QBNTFJZRm5oJpSKlzIbPLOwAGEU/7LKTgl9suRmBZFyKceKKaog1ZPfIQKyFDbg4adzhhnRf+Ehh/c8GnEbsM9v0crmSeCgVtNiFpSqj78ovTaXtvjuFyZ/XsPZ+ytx+vW/0l3v95pPlb52eeZ2zEjY4oA60h40CzHE731+T8FD1AlNEU/xp4a0rgwbgJiQ8d90RRfCv1wZ7oQYMoXaK7T1ZV3wiFLiwi2GGaLb8 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Nov 2017 12:03:52.1225 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 771ae55b-c928-451d-ac2b-08d533336def X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[192.88.168.50]; Helo=[tx30smr01.am.freescale.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2364 Subject: Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata 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, 24 Nov 2017 12:03:54 -0000 On 11/24/2017 5:29 PM, Radu Nicolau wrote: > > > On 11/24/2017 11:34 AM, Akhil Goyal wrote: >> Hi Radu, >> On 11/24/2017 4:47 PM, Radu Nicolau wrote: >>> >>> >>> On 11/24/2017 10:55 AM, Akhil Goyal wrote: >>>> On 11/24/2017 3:09 PM, Radu Nicolau wrote: >>>>> Hi, >>>>> >>>>> Comment inline >>>>> >>>>> >>>>> On 11/24/2017 8:50 AM, Akhil Goyal wrote: >>>>>> Hi Anoob, Radu, >>>>>> On 11/23/2017 4:49 PM, Anoob Joseph wrote: >>>>>>> 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. >>>>>>> >>>>>>> Signed-off-by: Anoob Joseph >>>>>>> --- >>>>>>> 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 >>>>>>> >>>>>>>   lib/librte_security/rte_security.c        | 13 +++++++++++++ >>>>>>>   lib/librte_security/rte_security.h        | 19 +++++++++++++++++++ >>>>>>>   lib/librte_security/rte_security_driver.h | 16 ++++++++++++++++ >>>>>>>   3 files changed, 48 insertions(+) >>>>>>> >>>>>>> diff --git a/lib/librte_security/rte_security.c >>>>>>> b/lib/librte_security/rte_security.c >>>>>>> index 1227fca..a1d78b6 100644 >>>>>>> --- a/lib/librte_security/rte_security.c >>>>>>> +++ b/lib/librte_security/rte_security.c >>>>>>> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct >>>>>>> rte_security_ctx *instance, >>>>>>>                              sess, m, params); >>>>>>>   } >>>>>>>   +void * >>>>>>> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance, >>>>>>> +                  struct rte_mbuf *pkt) >>>>>> Can we rename pkt with m. Just to make it consistent with the set >>>>>> API. >>>>>>> +{ >>>>>>> +    void *md = NULL; >>>>>>> + >>>>>>> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, NULL); >>>>>>> +    if (instance->ops->get_pkt_metadata(instance->device, pkt, >>>>>>> &md)) >>>>>>> +        return NULL; >>>>>>> + >>>>>>> +    return md; >>>>>>> +} >>>>>> >>>>>> Pkt metadata should be set by user i.e. the application, and the >>>>>> driver need not be aware of the format and the values of the >>>>>> metadata. >>>>>> So setting the metadata in the driver and getting it back from the >>>>>> driver does not look a good idea. >>>>>> >>>>>> Is it possible, that the application define the metadata on its >>>>>> own and set it in the library itself without the call to the >>>>>> driver ops. >>>>> I'm not sure I understand here; even in our case (ixgbe) the driver >>>>> sets the metadata and it is aware of the format - that is the whole >>>>> idea. This is why we added the set_metadata API, to allow the >>>>> driver to inject extra information into the mbuf, information that >>>>> is driver specific and derived from the security session, so it >>>>> makes sense to also have a symmetric get_metadata. >>>>> Private data is the one that follows those rules, i.e. application >>>>> specific and driver transparent. >>>> >>>> As per my understanding of the user metadata, it should be in >>>> control of the application, and the application shall know the >>>> format of that. Setting in driver will disallow this. >>>> Please let me know if my understanding is incorrect. >>>> >>>> If at all, some information is needed to be set on the basis of >>>> driver, then application can get that information from the driver >>>> and then set it in the packet metadata in its own way/format. >>> >>> The rte_security_set_pkt_metadata() doc defines the metadata as >>> "device-specific defined metadata" and also takes a device specific >>> params pointer, so the symmetric function is to be expected to work >>> in the same way, i.e. return device specific metadata associated with >>> the security session and instance and mbuf. How is this metadata >>> stored is not specified in the security API, so the PMD >>> implementation have the flexibility. >>> >> >> Yes it was defined that way and I did not noticed this one at the time >> of it's implementation. >> Here, my point is that the application may be using mbuf udata for >> it's own functionality, it should not be modified in the driver. >> >> However, if we need to do this, then we may need to clarify in the >> documentation that for security, udata shall be set with the >> rte_security_set_pkt_metadata() and not otherwise. > Indeed, we should update the doc stating that the set_metadata may > change the mbuf userdata field so the application should use only > private data if needed. Agreed, but it is dependent on which driver/mode(inline or lookaside), it will be used. Lookaside may not need this API as of now. Other implementations may also don't require. So this shall be documented that way. -Akhil