From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0068.outbound.protection.outlook.com [104.47.33.68]) by dpdk.org (Postfix) with ESMTP id B7F06293B for ; Tue, 12 Dec 2017 09:55:40 +0100 (CET) Received: from CY4PR03CA0020.namprd03.prod.outlook.com (10.168.162.30) 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.302.9; Tue, 12 Dec 2017 08:55:39 +0000 Received: from BN1AFFO11FD017.protection.gbl (2a01:111:f400:7c10::147) by CY4PR03CA0020.outlook.office365.com (2603:10b6:903:33::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.302.9 via Frontend Transport; Tue, 12 Dec 2017 08:55:38 +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 BN1AFFO11FD017.mail.protection.outlook.com (10.58.52.77) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.20.282.5 via Frontend Transport; Tue, 12 Dec 2017 08:55:31 +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 vBC8tXfr015459; Tue, 12 Dec 2017 01:55:34 -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> <45060b96-9b19-fe62-7653-5ad734188c93@intel.com> <7f193513-bfdb-81dc-48b4-ee844928745d@nxp.com> <9603b9ad-1aa2-a724-7dd7-4e8d2fb05f33@caviumnetworks.com> <40eaebc2-8472-f904-07f2-19325c12f3c8@intel.com> From: Akhil Goyal Message-ID: Date: Tue, 12 Dec 2017 14:25:33 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.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: 131575425321335019; (91ab9b29-cfa4-454e-5278-08d120cd25b8); () X-Forefront-Antispam-Report: CIP:192.88.168.50; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(336005)(39860400002)(346002)(39380400002)(376002)(2980300002)(1109001)(1110001)(339900001)(189003)(199004)(24454002)(5660300001)(110136005)(36756003)(2870700001)(54906003)(81166006)(498600001)(2906002)(81156014)(53936002)(8676002)(6246003)(58126008)(68736007)(65806001)(77096006)(23676004)(2486003)(65956001)(83506002)(59450400001)(47776003)(229853002)(67846002)(105606002)(93886005)(356003)(316002)(305945005)(85426001)(97736004)(76176011)(106466001)(15650500001)(65826007)(31686004)(104016004)(4326008)(2950100002)(53546010)(50466002)(64126003)(86362001)(8936002)(31696002); 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; BN1AFFO11FD017; 1:Aifir8dq7kpU50e8cj+dBJFsy9PLmIvPp9RvdbRWXkGC/6hkaUoz5d4+OW/DM8CdmZC+DmpDWRSAEL+t99F/F3dT0PGOkXIJvTzVPnQI7kVmGYMqhQnluOQgl5xDcDAe X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9ab6553e-fc3e-419c-f8eb-08d5413e19e9 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4628075)(201703131517081)(2017052603307); SRVR:BN6PR03MB2689; X-Microsoft-Exchange-Diagnostics: 1; BN6PR03MB2689; 3:cY+aPyHhz8gOox40yW4t0YV86DTB6XwNvhu97kYtMuyR+8NwwQY2Ot6yJVuFP81TGAudDrX+olG6aD5bqJsCNESBHvwRX9dXg9PMqswQjaJtzk5rk2ZmCR6V6E5vbrV4Qu0wlAuJoAgEMMajUOz9Js2jmrhEINh6YLG5R6KSKh3zavrqaETHxhUkwGonQNQ3niFFbls4os+LanagVk2AVkNFDd6y+pnW8ZQdZEekL0yNyBKjmzLSEdGnSPYjswpclemp/FgwDfCnzoJjbqlFkyhUKQiIHMQftW9muHFKkmBo2oLAIsV+F0MaH3dxasWHntMjEQn49dYpWho46aKyWGn+X4txh03QAHRdzmOMiWw=; 25:Bf3r09GGpf5q/+0rHRjYJ/2QTLX49VmzBJm2jx8EAjOBeFvnWD9RuEAttLUVbw7dYqo44KL91E0L1WOT4L/pVwSpgeOqj/n5LyZvL1z9fPnSSiMC0IiMcNPzn8TS880CisYqQJFY4xOpd/1+NfzmtVPct/aI7UDOtdxIa6A9rA9eKLTp6+aMRXwKo6x3u9RaX6am7M0KmgttEr2lA5wHuII+x6iT6pPFywCfnwccHqYV07skcL8y3R/asBLol/xr5HoochsEyKtZ3h0lDx3HXzhMbJJyHCgZj3AE9b/cu/eRswADvDTj3bhVABMMc5dW6HBeag0IR62cxUwr0f+XJw== X-MS-TrafficTypeDiagnostic: BN6PR03MB2689: X-Microsoft-Exchange-Diagnostics: 1; BN6PR03MB2689; 31:7/kKvknr2b9w6Xm25KMC1NLSuK9FoSl1tDh0n5XFNVRoMHCcWosKcIqQVFKnrRQp4W/hZXtPnidNPY2UjxK68Q1oDl3SpqO00gl35YOGmD471YeuFTzWy2pbCzRgcuxxRWtroyapQ+ZEvFVD3BZphscASF3Zems7z1xDElAECyQDyrPZnBRdGq6cIt/0BWHWiI9baFvN0Dlp46Ukc40qNr77MkM0vJQRk+Pi+eXxfKc=; 4:fnvs8iOAZ0SVEFTjyDF5amDL1yxDJBwFHbFcNnm6fPFP6s2BxV3QoXwTpMP5jIetJoHEAYb/rv7DmtlBI41s01XHo7gMP4wSm01tahRUxldiDZkieyPj5NyzciuSeFtuppfC+j3bZytvG0H4TH3WRyVIt1r+cmdgKr5cDcoSWAVraZgQwhj5szBTmV5pR46Ur0hBDpvHpjxXri6+if4q4SghrCPD3IlWVLGezsFlbDdPt0aHJ28T/tzmnAFSQTaFi9HzAZQRCbN1RkmPzJeZiGXGIa5yiFucCdRWgdAuQq45oZk8AGG8zN7WmW3vOO0d 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)(93006095)(93001095)(10201501046)(3002001)(3231023)(6055026)(6096035)(20161123565025)(20161123556025)(20161123561025)(20161123563025)(201703131430075)(201703131448075)(201703131433075)(201703161259150)(201703151042153)(20161123559100)(201708071742011); SRVR:BN6PR03MB2689; BCL:0; PCL:0; RULEID:(100000803101)(100110400095)(400006); SRVR:BN6PR03MB2689; X-Forefront-PRVS: 051900244E X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjZQUjAzTUIyNjg5OzIzOnc1b3kzSENTNFE0N2I2Z1hmQjg4VEMxcy9v?= =?utf-8?B?UWoycGVKY0NMaTdlYXNVd0tBeDB3Z0M3ajNvc2NPS203eVZ5ckxVN0Y2YkMy?= =?utf-8?B?ZXVMbHZjVmsxWWRTdndmMzZHeGRteGJ4VXVZRUxJcnNZb0V0amJ4OXc2NTBZ?= =?utf-8?B?dG1qQkxZbElOZHVwWi90b3FUYUREL2FnVXZKaVE3MTJWd0J1V0pTcnB6Nnla?= =?utf-8?B?Tk4rZis0ZzI3WGNncXl4ZEU3S1E1OFNGOU56Zzk3azkrUmhvRTJJMm9UcWtM?= =?utf-8?B?K09KY0t4aExnUXp2Umh0NEd6ZEppekpodk8yK1hIYUNhNFF3V2JnL0ZVZHN1?= =?utf-8?B?bm5CVzlPZUhDMkR2N3l6K0l4aTZJQTdvTURuakJWaDhFemNNb09weXNrK213?= =?utf-8?B?TElnRjNSdWNtenpjTFdUZ1VMM2tWVmtVQVVpMWY4Rk9tSzFJOUlIQno4RThl?= =?utf-8?B?NTVEdlRqYktqdGJyUk1aVGNzWkFSeUw1R3cwVjlIRVVTSXYvdUtYamkreDhB?= =?utf-8?B?SzMxbWo0VDBXeHRzeVdKN1IwdUxscExzcW84RFU0Um92N25aRTdSMDBNOGF2?= =?utf-8?B?OEpiTThhL3hZdUczZDkwWnhhZXhEbTN1cHV3QVhJZG9kQU4rRzFMVGhOK3RF?= =?utf-8?B?QmZleTBlWkVJbjVSUk9hbDYzOTF1b2VLa2E0SFA2SENrMzZpQm84dFJLZ0p1?= =?utf-8?B?TWRNSjkvTk5wNWF2SXloRDlXdS91bnFjdUNhakRlQnJsbmhrdDNaT3UyeDh2?= =?utf-8?B?bXMyZmNsZW5CU3pZeURtcEhoQ1R2UlFOQ2FUMTF5b3QrTE9pc3FhOEFCaTJ4?= =?utf-8?B?bE1qcnVwRERXS3AyeStEM2VKaU03WEF2Ykl3U3FxRjBCK3J4dnRiSUNjYVo5?= =?utf-8?B?MnZkVlIreWZYQnAzMVNvTDdQRERqZnRHMFNJdnd2QjhyZTU3MmZMcHgrdVFF?= =?utf-8?B?OFE3bm9mU3VtUTUzV3phVjFlWnYyaUpzMGg3cWpDY1BiRVg0SXZNMGQxaHR6?= =?utf-8?B?NHVwWWUxT053YW5Da1lBTGlBZ3BFQUtCSGRzVGxvakxmUWd6V29nckt1bnRj?= =?utf-8?B?M3dNN2c5ZjV3V1NzV1pRYXdJWElmL2M4YlE3QkpwSlJFeGRaT3dwdVlZK3Nr?= =?utf-8?B?WVBoRHZ3UFVYRi84VUtsSTVndXUrNmpaSlhoREFCd001VUREOUVMVlVpRTdq?= =?utf-8?B?RUdXamlFNEo2NS9LMWwxT1JsY2xNVEVEdDh6Z2xOL0tWYTdBYjBjeUNJQW45?= =?utf-8?B?YjlOUVlpMCtpTURsR0lselFocnlqLy9wamN4blR4Z1I5T1pyN0VGOVdTc28r?= =?utf-8?B?dlJtdHpIcCtPMHRVUjNWT3g0blcvU3FyZHBYdmFlNHRaZ0RrZGticXNKcFNS?= =?utf-8?B?d3BHc3dMWHZ2RW9oOUNLNUpiUWR1a2pVQkp6WEFEV0N5RC9Uc0EzUk44R1F5?= =?utf-8?B?U3J6Z28vNGUxdXdtdkkrb2lrQU1KZU9pNzBGSDBMaFFTOExPWSs0MGlzSDBn?= =?utf-8?B?QVRoR1I2bEREVlI5MGtmdk5uaFRlUU9nSkx0Q1JZbkN0QmRMNGI1T3VhdUhY?= =?utf-8?B?Y1BsckNGaURQVHBVYW4zSjU4Yk9vMlFBZHhJdGZNUWtxWFBneCtvcFg5VlVJ?= =?utf-8?B?THlaa0Z4TEU0bkUrcENieTVDTE5vTnlxNlFsd3RtV0VONnNKVWpCWXpReDM2?= =?utf-8?B?MlArREdnZTJUSFUxZ1M2RlhodjlwZFgyK0RtOHp1QzE4TUVTNHhEWVIzMXBB?= =?utf-8?B?U1MwTVZpcGp1TW9PS1JvaVBjam5wUnpid3BPZGhYWUc0bGVQYTd3cWZVNk5p?= =?utf-8?B?RFdLS3EvVTlMU1YwRHJMaU9BRkwxdTZnN1VpS3BncmJ6YXc9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; BN6PR03MB2689; 6:+S6x0aQTjlAEKNE/FthJ84h4/t9K/A/sB7dUJPoqj1ryW3+Qz09dJsoCX0lL3P2z3v1dR+IufkiMfplW1LKipMicfL8JzAX94t2ZauJQl0WiC3mkLxSH5T1xGJyhUgexihDjOw9iM3Ba8zVLkEBX2nHOCd4+kMs2cy7sEQ+xBrcqwjdVnFA62d4gv09UbDbj2O6ylcbVSR7tus1JcdTK8MP5IRZ20XLusTEmWXQ6UxtVruLoC3oZS4jc0CyWzzzvn+KQmfzqEGMHwGQUtRgaejYNfCQkyUsFa4RNll+wU56+tch2tvby4btB8GxN1ekvLqfl5Ehh36hmTGO12kArYnriLQ1Iw9aICEInnCBQFqs=; 5:md4IART3vcQj3FXuj8kDTMdXkL5T8PrJDA/2c9NQLfWWrPGvuK6HT0MdXjmXpTZUaNV1OZTTZ7MmG3kwjTn7fXv7sAtxj94xzdycrdEoAeG8WZTsK3rR/nlyV3Th0kOgOk085VDY/v2xRfsdbEjdNuoJf31mjtzcZv+9XP7YrZo=; 24:etZwIn+salabe5n1zMb02fAASe+RuFsGQ6jFlWE72Pd6mX9RXfO4opUULk5h3GM3Pbsr66Bs/rYu9W9bBhZLmyw+qqc3vlY0Pzbx3g7NNR0=; 7:riwMiHfLcPjTc3zBvU3iugbyOFAX/wW61x5eZOgj3NWG/wINIi9J/NAH1KtCpLFmanMoTO69A0UyEohkKmIGZyqmSrndqqmz4TzQsQmnKTCVgo7DOZt0rIFH3LQrVLCUMxF0Fxf7/Zj7NVX6kvrGG3MgXbNlBCpygYjldiNdGmtiZZSgk0NbmBQ2BGCseqC1B2qhHYvU1BzSO9NWUjlz55lQS3ynT7XO+msrV0GidkkAq7kFF84xpnGlmXoqxddL SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Dec 2017 08:55:31.8683 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9ab6553e-fc3e-419c-f8eb-08d5413e19e9 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: Tue, 12 Dec 2017 08:55:41 -0000 Hi Anoob, On 12/11/2017 12:51 PM, Anoob wrote: > Hi Akhil, > > Can you confirm if you are fine with the approach explained inline. > > Thanks, > Anoob > > On 12/06/2017 03:13 PM, Radu Nicolau wrote: >> Hi, >> >> >> On 12/6/2017 7:30 AM, Anoob wrote: >>> Hi Akhil, Radu, >>> >>> Please see inline. >>> >>> Thanks, >>> >>> Anoob >>> >>> >>> On 11/24/2017 05:33 PM, Akhil Goyal wrote: >>>> 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. >>> Is rte_security_get_pkt_metadata() expected to return a "device >>> specific" pointer? If that's the case, we would need another call >>> (something like, rte_security_get_userdata()) to get back the >>> userdata, right? Or is it fine, if the application assumes it will >>> get userdata (the one passed in conf while creating security session) >>> with rte_security_get_pkt_metadata()? >> Yes, this will be my assumption, a "device specific" pointer (similar >> to the "void *params" parameter of the rte_security_set_pkt_metadata >> function), which will contain an arbitrary defined structure that will >> be decoded by calling a PMD defined function. >> But I think Akhil has a different view on this. I am ok with the approach, if we are adding this as a limitation of using udata in the documentation for inline cases. The ideal approach should be such that driver should not be knowing the content of the udata. But, if we cannot do away with it, we can mention it in the documentation. >>>>>>> >>>>>> >>>>>> 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 >>>> >>> >> > >