From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0072.outbound.protection.outlook.com [104.47.33.72]) by dpdk.org (Postfix) with ESMTP id 14C4B1D8E for ; Mon, 4 Dec 2017 10:28:26 +0100 (CET) Received: from CY4PR03CA0082.namprd03.prod.outlook.com (10.171.242.151) by BN6PR03MB2689.namprd03.prod.outlook.com (10.173.144.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.5; Mon, 4 Dec 2017 09:28:25 +0000 Received: from BY2FFO11OLC016.protection.gbl (2a01:111:f400:7c0c::146) by CY4PR03CA0082.outlook.office365.com (2603:10b6:910:4d::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.282.5 via Frontend Transport; Mon, 4 Dec 2017 09:28:25 +0000 Authentication-Results: spf=fail (sender IP is 192.88.168.50) smtp.mailfrom=nxp.com; caviumnetworks.com; dkim=none (message not signed) header.d=none; caviumnetworks.com; dmarc=fail action=none header.from=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 BY2FFO11OLC016.mail.protection.outlook.com (10.1.15.61) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.20.239.4 via Frontend Transport; Mon, 4 Dec 2017 09:28:25 +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 vB49SKN3026189; Mon, 4 Dec 2017 02:28:21 -0700 To: Anoob , Radu Nicolau , 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> From: Akhil Goyal Message-ID: Date: Mon, 4 Dec 2017 14:58:20 +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: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Matching-Connectors: 131568533052085527; (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)(39860400002)(376002)(346002)(39380400002)(2980300002)(1109001)(1110001)(339900001)(24454002)(189002)(199003)(86362001)(85426001)(81166006)(8676002)(97736004)(5660300001)(53936002)(83506002)(67846002)(65826007)(36756003)(50466002)(2950100002)(356003)(8936002)(31696002)(15650500001)(2906002)(23676004)(305945005)(81156014)(54356011)(2486003)(53546010)(2870700001)(104016004)(93886005)(54906003)(33646002)(106466001)(31686004)(105606002)(76176011)(316002)(229853002)(77096006)(58126008)(4326008)(68736007)(65806001)(47776003)(64126003)(6246003)(498600001)(189998001)(65956001)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR03MB2689; H:tx30smr01.am.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11OLC016; 1:4wDMbWOVyubrL7DU+uYhUlXC6KV8dSt690CvQBD7aD/i76EZgNKcp/o2rffV4mMf+cASmt8VI/jDI7wk7RgBPjmGAXpL1VE9uc0Tw87OU2xd9NCdu9khZROH3AdaHgRK X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4b6fb4b0-076a-434d-5517-08d53af95ea7 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4628075)(201703131517081)(5600026)(4604075)(2017052603286); SRVR:BN6PR03MB2689; X-Microsoft-Exchange-Diagnostics: 1; BN6PR03MB2689; 3:niYnI/v/jrdfyCQzKgeOHzupomU6URFj2oU+t4EAmgg5JJY9Y/RpHzebUr8IR+l9QRxZPcSQlSiCgeVO+Jw2nNCcTeWPmues6t1rjYlHHWOokf2o63LfyM4ftcxVIzlxsMPKgzEQNObGcjg8LTFQH6JN7xIVLnfWjfNBUZgpSmrM+D/3C5oeVhLctU++AdI9gmvgbHMR2tjNPCRNrklmHMoKi2eXWarYMRx5qfsghVMPTinK6+37SRUiBPGNrsskj9iLf0GxC6OL3QUvw8bK4/MzOCkJAjkEiTi0Jf5rCzon695eoKS6rcgEx5IXnjyKgVPwu5pUpqVNoMOKX8l8W5VtN4NqfOFzNVduHBrR1OQ=; 25:/qDRHsyLq+uDv5hBDdEy8BYEAqknQ7Nmxgff+kCb/SVubmkB743rRz1/ffZl8gKrZWWXIcsHOrDlpFpD8N1KKJE/c6IhHLXccGXGYsNGs6WIuVdTs/fG4hwO+/UnB5YHyW0rH6KmA2Shdm6gu5SlRwiL6gcw/CU8RPxOwBvLJsVh94pMl0Ww6eTslo1oIWLhrrYCT5y3h0GCTfYvc6jHjfuIJg0fl6ZUhMRDLgXqb3N1oCVr2pHIYZJAXD8x0OC0/a3ffkmJwcaPvCst60gJYhi5PF1niM4NgQbHaa0FrkgKuLpXCwFfWHilNAKSHv2/lsXXqQD89M6/R/9mYZmFMg== X-MS-TrafficTypeDiagnostic: BN6PR03MB2689: X-Microsoft-Exchange-Diagnostics: 1; BN6PR03MB2689; 31:GcoApjZjrJEb1dy1eHDmE+FFkUAxq1FkEiKuMqCKefs/ZUm2pksCJrxQaLYytgCy0lWP5VrqdNSybsLgE/IdJK5ehTbhz8IAtmFd6Qn1jq72njyOd0sk1Ex67IVjp8LPBFJJXfH6rHmRh1OrIV4AniiwTC23d5M6koakURKUvBULgYTqd7fz3tfowDPoU+cnwN3AITA+uVagkIEfRU2ckDDzEBSBG0m0aSH4+mWCvsg=; 4:ODWmYII/i4mf/n4GRxeqFpy8kKBDjeWIG9KORx1ylQYvIgM1ry24zDzwIYxUGps/mwpFgh9bnEHlb9IwWD2hE/qsQXuoLwDdI7mNBVw9qfSvDBquRSszzf7M1lMc5St5vQQr0+5zmqLGbuxPz4SDFCOqpuiKUfj9KGGOytmGB83ddynSk7s6r/bgLgDPpTG8CVnRhtw2lrPFZ//0AqulGH5k0jTaTfa4Z1mErsfW6QJN0JjaO/EQHpmZUGBLdmJGCR87SfkQKYtNo06j3EdNtedzFm7+wO8cXLIifUi/F2e/Xt7t8r/NBQ2Ju8CGNVD5 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)(3002001)(10201501046)(3231022)(93006095)(93001095)(6055026)(6096035)(20161123559100)(20161123556025)(20161123561025)(20161123563025)(20161123565025)(201703131430075)(201703131433075)(201703131448075)(201703161259150)(201703151042153)(201708071742011); SRVR:BN6PR03MB2689; BCL:0; PCL:0; RULEID:(100000803101)(100110400095)(400006); SRVR:BN6PR03MB2689; X-Forefront-PRVS: 051158ECBB X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjZQUjAzTUIyNjg5OzIzOmR5Q3pIR2xJdTM3THN2MXRFUkRlN0ZQeVpV?= =?utf-8?B?NGdLbmhPc2RNM3RlM0VtNUZScFcyVU9GeUFzQndGQ3VLSFI4dnNSd0ZtSVdZ?= =?utf-8?B?cTMrVWJvbWFsQlp6V0VScHM1RG53ZzFzTGFxZDUwOEsyUVBXU0hCak5wNk9J?= =?utf-8?B?Rm45UC9XUXJqZ3R2N0FMWW9Ea1NHcVhlajArZkhzK1NYK1ZtQ0VLQU5NV1ow?= =?utf-8?B?YnBER2FHZnE0aGczdTZJaCs0aURQWThpSktRRXJHQ0JaUmdsT1d2WDc0a0Fj?= =?utf-8?B?cnFPZTJPMHNCMVdSeng5Ync1WHdFK1NpSDZIazRBOFNIOFl6YUVUOUJjVGZm?= =?utf-8?B?TzFFVGdDRWhEaFdXYWM1bm9XYjdBNXJtTGY0MzVSdWw3SHBmcm05ZEdoQUhp?= =?utf-8?B?NlpoMDZjMWhyeFYyL3FWYTdsYStnZ2MzQ0xYSlBWRGc4dmNGbk9GTEpXSDNQ?= =?utf-8?B?eXhLNEM1TmZmemROYzZ6d3V1ZDhqaTdUajA0TmJUY3VCcXAwbGxnY3Vqbys3?= =?utf-8?B?QThtYWVpeTJTSHg4QXlzUDh5THpiU0dENkJPczlhdU51NlNvb2huYzJVUzA4?= =?utf-8?B?K3p3eTVGMkRPcC8vcmJBa0YvYUY3RloxNm5WK3A1Y0hYZlgvSmpTek83OEUy?= =?utf-8?B?ZjBGeWgzVFFtTXM2bk80cUV1YWVRVUhxNmVNVTM4ZXExQ3BkaDh3UitYbTYw?= =?utf-8?B?dGp2dW1xa2lxZGV4dE50dlBmWGhWVW9PVWd6WWxhL1JLd1prTjIwNGU4OVV2?= =?utf-8?B?a01US2pFUUxYYlpXMVhKOFlCcy9BazRkMm5hRmdMU0loM29nMlRFdHhtZ05w?= =?utf-8?B?UHYxV01YVDMwWnRpWVRsU3lEWjN2OHpURDMzcmM2b21PenY2dUpkQVRVN3Uw?= =?utf-8?B?L2w4MHNvbzNKSXFIMnJXc0lXSGFzSTd6a3pra09ZTlhMRWMrQi9jM2plQjIv?= =?utf-8?B?MFRKYWxiN1M5UDNSNUFyRnNqaUxNL2F2Y1hzZTdvR0drRFNlSklTMU1TMXJF?= =?utf-8?B?R2t1T0JtM1ZuUGZQTUduVXd4YktwRTBxS1h0ejJKckJhMXpTQjhQUndlN1JZ?= =?utf-8?B?MVlRM0JxS2FxWlAycy9MbEpEM25BVEh6NzBZUnk5N1FpOVNibnJrUzJlN3py?= =?utf-8?B?RXdoZXdvaExLeENSUDNhS1RjMndndFh0UFZoT3Fza3NnRmc3WElEdkVnWlAv?= =?utf-8?B?a2dWOXNtMjdpOW9ZVDl1Z2V1dUQ0ZmlpQk9JOTN5R2dleVpBa3pDQXBNZFVt?= =?utf-8?B?TFBqcjRpRXBxdExyVGFOUHNzYmExT0J2blNKWGUxMEJick1MY3RFZU5BNmt6?= =?utf-8?B?NlcvUDA2cnNMNFBwblF2YjlGTHRFN0drS0pSTmxlQTZqaWhZbTVKSHZYdk1I?= =?utf-8?B?VW9wK2lXMm9FbEJxeXp3V0dRVDRRcGZWMlMyYVFHekRlR2hKanltS1RxOGxK?= =?utf-8?B?TzB1SXFYeTV1Zk9vbXJvMWlLdklZVkFwTDdwWDJmSldtUVh1bDZDcVZ6TFYw?= =?utf-8?B?RUtFSUVSUnJ0b3VNcjlmUzlUOVhVUlpUMFllMURTeUMya3c5bFp1ajVpbVo3?= =?utf-8?B?bmdNZ2hOM2JCQ0luTURwTy9YaFFCcVBUZjBUc0E3TVA2YXJRV05XVmJPdk5I?= =?utf-8?B?T2gvWkozQk9vWkdZbXpCVVFmZ1lqUUxjZEFSVmNMWkRsZHBmZmJ0eFl4Ym5F?= =?utf-8?B?N013N2pEd0oxV0xUUEN2ZXE1dWxkODRHWWQ4bk04MVZoMWNrYWkwUmpibHd1?= =?utf-8?B?L1lPcDBKdUhxQjRKZ2tyMmFFaTBYb3dRTTAxcVkwQ3V2azZacXJncFBaRTZs?= =?utf-8?B?VHl2TjZqd0x3QWtyQ1RnT2tYMVJHUGN2ZDIreHBzMStyT0tyRE1HeGl0T3RT?= =?utf-8?Q?Cu80K3cTmAHHqzoU9EWzkr0Rp2NSdOiO?= X-Microsoft-Exchange-Diagnostics: 1; BN6PR03MB2689; 6:bsFtFAC8Uy0Is3JReaciWT2G76WFm4nEhI3Xj9T/NibLj+UwBd2RZJdPvD8xb/tcW19B75Gx22OGRV0tGMiIkuGZJCBRmp0D1gvOjOdLAXZdhIxE+44RMKr21zxKCwYF5x4INNQAJS4+z3sreAO3l6BfDAWJcwSdnZutGV3WnGuOH2eUDuLxjK0qQ3agk/pk3zFEffHRpYfpVm4VJIVbz0CmOQ0ap9F5N2HpH6AYdoIGQBATI96+aejBW9Qf1vfarl3K1DgNDRBdVJENp4BqBAxkIIizsvKQriAbSnKYHsslJJtFWAt+uc6PkYfeAFDeM/1ieSAceN2lv0Ac07GfJoLk2np6lIGHo5rZxaDtvfY=; 5:eWPsFZmjH5YzM+LVqfaowQs8yHO8NQ/GUhb7VnGlUjMO6GtGv5QGrw5JkQSzCPEQBBPGJ6e6TBSqUoAHihinLSvkatWHKEKGtdkbhCdRYQ4xVywVU0wC4J7hitQflYIkJyGSOvc3aYJLDPRzNBF7uCbv4imYjnEsgWQC1HVpL7E=; 24:O6591ZZhsP64IGhMMesi+0Sv+cSONT/Zr2PUuPVwSXbUEcOilq9rl0eMLVId1Twh/ng+218HySqwU9TD8PQlgKP9b4yIXChlAqmby+u++JE=; 7:RjU6LnS/Zq2tXre7xkXOmJGKKu/MG0jAedXj4N/PK2TtfUssmzwxxDyHtJWjeajMwbTRARcpb1H4+1QOJjpcVBank0nIRtMtyUcH+SS476R5CJsazJXuG/35yFEAOy8MA/QGwaVTNjEA973YVjQhciDvbb4k7aN8mNHq/H5CdGiZ0qpFDxK4S0wIwrAV8uwlRjdr7nXIpb3DBsBllvdbJnSc5h6TONTaP/eNhXUrjuc4yu6FIbSb/XMxcY3Ou8cA SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Dec 2017 09:28:25.0213 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4b6fb4b0-076a-434d-5517-08d53af95ea7 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: BN6PR03MB2689 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: Mon, 04 Dec 2017 09:28:27 -0000 Hi Anoob, On 11/24/2017 5:52 PM, Anoob wrote: > Hi Akhil, Radu > > PLease see inline. > > Thanks, > > Anoob > > > On 11/24/2017 05:04 PM, 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. > My first patch was along those lines. Can you take a look at that and > give your comments? > > If we add this metadata in rte_security_session, we can achieve the > above behavior without driver maintaining the metadata. But from the > packet, application will have to first get the security session. And > then application can get the metadata by calling "get metadata" with > rte_security_session as the argument. So we will need a "get_session" > API(which reaches the driver) and then do "get_app_metadata". In that case also, the application cannot set metadata independently. It will rather become more complex. It is better that we document this properly in the documentation as discussed in my/Radu's previous mail. >>>>> 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. > Your understanding is correct. That' the requirement. >>>> >>>> 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. > The requirement in this case isn't exactly parallel to > "set_pkt_metadata". May be we can drop making it symmetric? >>> >> >> 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. >> >> -Akhil > >