From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0060.outbound.protection.outlook.com [104.47.32.60]) by dpdk.org (Postfix) with ESMTP id 08B362030 for ; Wed, 13 Dec 2017 15:38:10 +0100 (CET) Received: from BN6PR03CA0006.namprd03.prod.outlook.com (10.168.230.144) by BN6PR03MB2690.namprd03.prod.outlook.com (10.173.144.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Wed, 13 Dec 2017 14:38:08 +0000 Received: from BN1BFFO11FD022.protection.gbl (2a01:111:f400:7c10::1:147) by BN6PR03CA0006.outlook.office365.com (2603:10b6:404:23::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.302.9 via Frontend Transport; Wed, 13 Dec 2017 14:38:08 +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 BN1BFFO11FD022.mail.protection.outlook.com (10.58.144.85) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.20.282.5 via Frontend Transport; Wed, 13 Dec 2017 14:38:01 +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 vBDEc3me028815; Wed, 13 Dec 2017 07:38:03 -0700 To: Anoob Joseph , 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> <5f2245e3-72ea-e529-1620-a0d96fd0c675@caviumnetworks.com> From: Akhil Goyal Message-ID: <9a2b458d-aca9-1cee-b77a-0ad04f69f866@nxp.com> Date: Wed, 13 Dec 2017 20:08:02 +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: <5f2245e3-72ea-e529-1620-a0d96fd0c675@caviumnetworks.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Matching-Connectors: 131576494817171141; (91ab9b29-cfa4-454e-5278-08d120cd25b8); () X-Forefront-Antispam-Report: CIP:192.88.168.50; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(7966004)(336005)(376002)(39860400002)(39380400002)(346002)(2980300002)(1110001)(1109001)(339900001)(189003)(199004)(24454002)(64126003)(83506002)(5660300001)(65956001)(2870700001)(47776003)(50466002)(65806001)(2906002)(15650500001)(4326008)(31686004)(81166006)(8676002)(97736004)(36756003)(81156014)(356003)(104016004)(85426001)(65826007)(305945005)(53936002)(67846002)(229853002)(498600001)(316002)(2486003)(77096006)(6246003)(23676004)(86362001)(8936002)(59450400001)(93886005)(110136005)(54906003)(68736007)(31696002)(2950100002)(105606002)(106466001)(58126008)(53546011)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR03MB2690; H:tx30smr01.am.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD022; 1:/9l1HEP+Dshs8ZrsNaMxxi4s8/SSLCs3JMOsOX0tG2WTJYRcY6olkNUMdLPHd/BYQsfD/vufaFWBF3YdgNiEO9ikGU7o3tTkvfiwnRU4nwNdJ0hoMELo/ZpHGS3/5eKA X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ac0428d9-883e-4cb9-56c5-08d542371cd5 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4628075)(201703131517081)(5600026)(4604075)(2017052603307); SRVR:BN6PR03MB2690; X-Microsoft-Exchange-Diagnostics: 1; BN6PR03MB2690; 3:g0h2CRrDRq9m/bvKyRbncFJ9iwUklBebe508RaCLq1SRU4KQs7jdx13JHEBRRANnjKmJmqBL5l+Ml9eAI4qdko2+DkfxjoNoRhWzLbeTpv7ncBz/ubo+Etr0+NrES6MoNeAVeEaozUnQggMFRrfaSgAcznByCs1CfT1ooGCUFHOPHYfdXX+uurodZAuCqNOZBwvLXOPcCfXR2gyrErjTL3SMGJHqM+JNRu/FHOKoho6BM2DP0SJNHjyKnW/VPQMbiIB9qCNsT/83Wz8kxOH3HainPwMWarn/mOdnxDpfYtOKeBM3KyQTCUqLiUFmdGGHDC/kX/S1sXWU0nKZSDBiWc/n5/OgdzT8ipr5BtzLVpE=; 25:gw/ba2XHogEjmkWKTstU5QtwXdrlK4Q9qDR4GCT4Kjhk/zzUIufRcQvE+3d9qBRfCszVe7VhIUzsZFvEiYs2lZ1K/29WdB+QWHJ/ZUJCqRdUiQxedg46BT3qyaXtzR65HM7iSILjvXtB0/Q2IMCFqtHFgIyM0AQSwSUvNB2KxNEPzM7/uBY1H6mpkuLCbG1i31jcRAxajyiTt7oNHuA5QzFH9B9IQDUe9qS10pyBdEw4qbiuQzby75KIMKCq2ZX5wINruX7LVSVn8AWIFFqxquSMstfcuWGBQISP/aiL6jAcz9K9fAulqdiWHyoUeuJTCDkBp2EX9DtM3nf14VxY6w== X-MS-TrafficTypeDiagnostic: BN6PR03MB2690: X-Microsoft-Exchange-Diagnostics: 1; BN6PR03MB2690; 31:WJ5pjBoHKE91CV/9XffJ9hvosZO/wXshEgdUHAF4g/fqx0xe5pFOeOVj8DP7DO0fVvzw1YhTTtjlDqVaJbsCSfqe1w5S4K1qv6znXvv0TiiClJjByTPjHKeOvkpu6DEZFJBnA6U+9VJ+TkeH0RqrgyEo+sM8rjqJbFVjFE6Qgpo1RUyQEhrIa4QkxA9rjVy0qsgJCnvhIXU96GUnbF45aAX0Hq6hKAAxp6SIrCij/mc=; 4:V0EIU3QbIWcEE9KAKWGl17TXsLUnAJUQFCfYHzM/SSYpsqOVASTlt2wyfLFoKsIkINlGWXoEF+oBcQLnZhdfrIFEFLknsh2WWLRABn4yLfb1iXbmyf6Aoam24M8FEFrEB1ppNRLfIsX2rSagmx+J9UHapOBJvTaCMaiLsfJdm3UEd9DC+/kYpb6hZiIfT8/MSqzTEtaNCCU/fh1+sbdLdh6E6B+85zdAjNOZ38D1Mz7FWKOUOh1B0FGYkHYE81C4zMInn616rzNJfrT/Bno3kX6VeiCr5k493tG8ItDlw9Sx5Awj78PNLVZZNscZRJ2AmL8Qi0DN1xDHl8eIgK7WkH9Z1/Wec//yrdvj7HWYYNw= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(244540007438412)(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6095135)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231023)(93006095)(93001095)(6055026)(6096035)(201703131430075)(201703131441075)(201703131448075)(201703131433075)(201703161259150)(20161123561025)(20161123559100)(20161123565025)(20161123556025)(20161123563025)(201708071742011); SRVR:BN6PR03MB2690; BCL:0; PCL:0; RULEID:(100000803101)(100110400095)(400006); SRVR:BN6PR03MB2690; X-Forefront-PRVS: 052017CAF1 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjZQUjAzTUIyNjkwOzIzOnNyN2tjekFYMGRqYU1JdGtWdHNmbTYzNE9J?= =?utf-8?B?Y0lrR3hlWGY5OFVIVFc5T2tseUc4WkRiTGoxaGdJdUhneWJTYnRxRzVudVVh?= =?utf-8?B?YnBDbVV4TkhjUEZnSFRmRzJScVFZMCtTNnpOenJQbEUwR2w5YVhzOTkxSGpm?= =?utf-8?B?azRYeS9KYWJWMVpDaWc2akd5QklmUkc1YlRCK0V5S2NqTk5PazVMVnhCUU9Y?= =?utf-8?B?aVd2eThwWnFqY0ZZMDZVRjViMS8vc2YrL1pVU1dVdm9Pb3EvdWJUOTdFdE9W?= =?utf-8?B?ak5nOXp0dzRMbDVRQnh2U3ZKMlFVZ2VjeGNtQXpObzlGaGJ1amcwVTZESGgv?= =?utf-8?B?Sk9zSzlYN2xkcTBHK3ZJZDRVbkhwTXJmK1ZCTGUvRW5oeXhRM3dvQmVwUmxP?= =?utf-8?B?NWhvTEdERWpkc2xPT2pEVXQwUm91ckZoWnpNczdPR2lLVElCT2Q5V2xFOGxp?= =?utf-8?B?dnE2cFRlLzBuWURLb2FVQThubS93Z3BqNHRZSjJrbSs1TkphTEt3dXI1VWlS?= =?utf-8?B?Z000V0tncjQyRzZxZ1FISlFISUhxby9lT0NxQzgrMUkwRStjZGxTd2xGMjI2?= =?utf-8?B?akpVWEwrcFpES2JTbnpvWVNaV1IrWWVCenlYeEtuT3BuVXVpYU0yTzM3RGc1?= =?utf-8?B?bkphc1prczhyZWNJenNCTlpjSG84M1FkWmJPNTVOaUR5QlZyayt1UEdSaFIv?= =?utf-8?B?SkJKbDNnajl4YVJvWW5rOUFwMTd1WVIwN0huVkZoVkp1NFlrdHVqVUNFcWJx?= =?utf-8?B?anFVVUJYRnhTcEJCYzVuNjFLblhlYzVHMGUrMk1TeVhvZ0krSUJOQ0Q2alZp?= =?utf-8?B?OGxrZUdDWVZFdU1HQms5U0l4R28vL1pWa1hUMlFydDNCZXpiY2p5blRlSUhi?= =?utf-8?B?S2pOVzlnY3E4WEZMQVRVaUJnRjgreFBzYWFCK2x0U3YzK0NDTjdyRFNPK0dv?= =?utf-8?B?TXJvREY1L1BHZko4UktMRzB3cHNxY3EvYUlpck1XQ0p2ZzBOak1zaTVVbE16?= =?utf-8?B?cXd5R3RpTEUyai81QzFVajJiY2VWYTVhZFcxWDE1ZHdtN1NpNXZXOHNmeTNR?= =?utf-8?B?R1BXbk4rNmtBZE4wc08zQzl1dFBlMUlqV21pYS9SaGlUUnEvQ3hINnNkVlVH?= =?utf-8?B?b1JyQkVLenU1OWZlRUNOZTlLcnpTTlNpUVlSVFNYRExJeTNtYTlPa1RnN1BG?= =?utf-8?B?aVR4dFVsNlN1TldxNTBqV1ltM0x6L3RDZlNyeC9HVWs0a0R1dk9uMUZRMWtq?= =?utf-8?B?dFhNSU1Ib2NjSWFNdklXK0ZlVmNWM3dyL3paTytZeWVYbUovRHlTbzBzQmpp?= =?utf-8?B?U0NiUkdaY2lhWnNHejRxRWZRT1pqQlVELzRKeEhYZWphbU5lTEs1Mzd5R29r?= =?utf-8?B?WG9UL0tpSWlxZEM3SkZKVXNJSnVXVER1U1dpRG1EMm1xYVdOZVlTdURFQUNk?= =?utf-8?B?NDQvU3hvLzA4c055SlpERHd3M2ZRd3BMVDlwN3VveXppZE1MQndNZWVjdXhz?= =?utf-8?B?bFowZThBYndjTTErendwdldHVzlwdXZzMk9hRjF3bjdFaUpCUEtmVEh0dzVN?= =?utf-8?B?aHk4SVA3QkJrY01wa3UrTFhIbm51WFZkUlFZNGhJVXRlazQ1WDY2SU8rSHdV?= =?utf-8?B?NmJJSXBsYlpjTGhDOVQ4eUZaSGkrTTR6VzlSUWxFME9iS24xK1VrbTJ6Ym9p?= =?utf-8?B?WE1QcXdCYUdFblBKVCtOUnJHVVRsbnJPRVlJK1hZV1FiYVpBUTM2UG43Q3lR?= =?utf-8?B?VXRQaFBYM0Rmd1hZYW1zc1NrNXBsSDgvODVDTGR3dnNOakxwWHNTWDJMd0VN?= =?utf-8?B?WGN3V3VOSS9VcU1PVisrMk5Da3RTdGNqWkZrRTErZmpwK0V1OEhEL0xLNnZI?= =?utf-8?Q?tmBI0WTIhZU=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN6PR03MB2690; 6:5C/rXiy/8XN7dnRggIxcc3zTLUY16Ah3AazmOBV0+tDdNe5heJXkmYCt4XR4spNt1XUXIBxIrsDXbsRSs9WIP8qnrCNzx7zKWCLpfOgthDkiy0Lp81Z4Z7E1+exkIPfpRhl8G6c8oTaI8Sc4USrFnS+6EVsf2aQnT84axcWFxTyITJMKwXTnF8oaHTQGYzyMaXYPZIdvqySwVAqyia+of3fyySMNvWvBEytkLvkQSQXPdDAY7zUpX64WVnZQJtXrDjgmnDiJy/uHKu5RpBBawujeZ4o7nA+CXgDFiRpmzHmmkgtHB6GfqBuaZTQXRijlhtODhHNcG2DFDA8zpQgx3UUxN0fyjzoOzxzS61+YR9U=; 5:Ug32r2LBOAAud8eEPpyvKaPH8hmpv6hvgFGq22W3w5xBrjEDL9qbOMNzC/DKJsfbItUayamGuUW2/cGpz93pr9gtUakw+ySzdCQHdfU7R7+TiLGmBmP8nmKBYHzBQcKDEq6b+fim8hn4Ncb4pbaLWzmbdpTISpl9RL+OHYlnoOM=; 24:wYJ+LHe6rqNOZkasIBTILZcKuHPN9W/W/MYLWW6932YN9p75R/uWxE6DA49UBRdHDOSnl8C64S5Uw70Dz/n0q4jR4Zs7SuTKuzpetVERzcM=; 7:mAIHOBsQ+qVz0niD9XK+DvI+pLbaMtVOWq1TefdETGIV1WRE97H2rYq2EkxIk9gRMtpr+dtI/rNC7cNup8tl1/tqPTOawMIXQ4TMFDHrrJYfNWjk5DASjKlsEkRUH8nZpsgg2zROMj+lXz4ETrG43T0zjdWys0NRFESVml/5jTJVBH3VO62NBhip1C5qYOKseR/ChSi97FmrttENhk8NgZ5gNzM5JAcaMDpVrUjKu0pTY1xWWOe7t215USlG07Y5 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Dec 2017 14:38:01.4519 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ac0428d9-883e-4cb9-56c5-08d542371cd5 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: BN6PR03MB2690 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: Wed, 13 Dec 2017 14:38:10 -0000 On 12/12/2017 7:20 PM, Anoob Joseph wrote: > Hi Akhil, Radu > > > On 12/12/2017 02:25 PM, Akhil Goyal wrote: >> 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. > Will document the limitation of udata64's usage. Since we are > documenting that udata64 will have some device defined metadata, do we > need another API call for getting the "metadata" > (rte_security_get_pkt_metadata). The driver can set this metadata in > udata64 field, and in ingress, the userdata could be obtained with a > single API call (rte_security_get_userdata(*instance, udata64)). > > The application will be aware that the udata64 in the mbuf will be the > metadata from the receive side, and userdata can be retrieved only with > that. If application need to use the udata64 field, it should save this > rx metadata. Userdata can be obtained anytime by passing this metadata > to the driver. > > To summarize, > 1) udata64 of the ingress traffic will be device-specific metadata > (documentation change) > 2) Pass this field to rte_security_get_userdata() to get back the > application registered pointer. > > Is this fine? It looks ok as of now. > >> >>>>>>>>> >>>>>>>> >>>>>>>> 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 >>>>>> >>>>> >>>> >>> >>> >> > >