From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0046.outbound.protection.outlook.com [104.47.36.46]) by dpdk.org (Postfix) with ESMTP id 4964F56A1 for ; Mon, 11 Dec 2017 08:21:56 +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=U5B0Lpa5oC3BmB3DPPrJ8jsS1PdoEk/8WMP4Azhz36o=; b=JL7hbtD/uslYozb2Ap6TCRtbfF3p/rSt06IkN4x43N9+DuvsSiwE68N/GuLBparqxfGNh1BH7DeO83tLXw1t6633Y3xyEeGHB6QMNlXTzNhj9gt4cLHbq1BiFiA3OqVXDYTp3258c3A0hQySH1sIqcb9m856OQ2Z5gxNa+IIASw= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Anoob.Joseph@cavium.com; Received: from hyd1ajoseph-dt.caveonetworks.com (115.113.156.2) by CY4PR0701MB3635.namprd07.prod.outlook.com (2603:10b6:910:93::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Mon, 11 Dec 2017 07:21:51 +0000 To: Radu Nicolau , Akhil Goyal , Declan Doherty , Sergio Gonzalez Monroy Cc: Jerin Jacob , Narayana Prasad , dev@dpdk.org 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: Anoob Message-ID: Date: Mon, 11 Dec 2017 12:51:41 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <40eaebc2-8472-f904-07f2-19325c12f3c8@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [115.113.156.2] X-ClientProxiedBy: BN6PR10CA0034.namprd10.prod.outlook.com (2603:10b6:404:109::20) To CY4PR0701MB3635.namprd07.prod.outlook.com (2603:10b6:910:93::10) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e4376898-3e25-4699-52f2-08d54067daf5 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(7168020)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:CY4PR0701MB3635; X-Microsoft-Exchange-Diagnostics: 1; CY4PR0701MB3635; 3:Wr/2S35fVVPbOitqiAiV1ZzC8AG1u9EhVqgkadHD/z0fwch6+j2U0WQJGSMHu3+mRG9UOftlynmCUXScJ9zVBKIqIFumewMVfYXR6KY4XssahT1KYtkpzh7oswUfV9cp2t4tUb0myfDtVqT13iGtr3h8P015irfBB3GiDQYKiubk6ud4pZxPl5e0gUiU8D9N4QaVdZPmb+sCG0SATka9aMvGtFP8XUHthQJjW+U4NvtxyRzmkUuSx102JCKn5XYj; 25:cEXJZVaRNGYRagrnMJDcRKfM8J6Yn7tRuRj/EG5zGLxFN0s7p0lNmMO41feL/mJ3BjfT9S0+1W1Chd1WgWZogaWM7X00Ah1XJvOPH1UIUqDqn5TTLNZc93qWWcpqP2LVUTZhcFDzLD7ER4DUJrxLo/G+p8NKkahPJI2y6iTKj3816vKl9H4G5vIPTy5MQIlPfsdOx9Dql1maR98t/geS5G2LiGkEtBfEnopOXEtbecTD1UrIIigcnt00x1tm+m1NI2cqa7Ze/ZdsXwNtqH312KlBGl9D9dV5CvEkrA8xwTZBFMtWwTamj8AjSV3r1JDHjsbcABbk6gO2vFIvBWCKjw==; 31:Xf1W/jkpSRbrTilp6/vXz5p3BQnCN52KioWCS2Zv1Fefi2EeRqCG0f1BSh22jiIK25abWMJKBde8/3inDJDPyKljhn5fcTc0GUOtpQrZrfT3aj4khoresbDowOY0GwMsP6hN0f9ZsKBS2HjO7EoC0fCBaXco95kHOFph0LBJr1FvTtz8nusn0bWzTYOLgjl8fRp5aMc7eOUZYztfOiVyEr5nrypiQAG5iYYWWeqx5xk= X-MS-TrafficTypeDiagnostic: CY4PR0701MB3635: X-Microsoft-Exchange-Diagnostics: 1; CY4PR0701MB3635; 20:jAsqBDRF/6iznbUrFbHgWP+QUQVRhLepnnrl0VcAX5/w2ZKSuWcew0vgXYM55Ag8VWpdO4pyxMiM5su/zwh0jgoO/BejWbq2L0MO9rGaH61nANLxYGmalAu+cOaPWdYv1R9E8rqXvoPGwteLNCs/rOUNjPJyPd999iXXzTHo/SAiFMuBwwLZfg1AoE0jW8DtoYCJ0W8LZHY/ZNRKw3akK0cbMR00r4Ifsy+JS/plsU3t0qQdz0/nX0vMSmI3I1YSbuxdHFfCEwOcGn6kpgzvwlj1z+w6xVHOMGlRkw+CWiNbB6fo/LmA/79OBbiL77EZDzPKg32auvJn8frfG6b9F5IsQS4zEDfaGyUKx592GGQhx1NePv2AnWNro4NDt0OuEEniQE19LZrtzfB3cFa68WOUOYpG/DCllHyYfKWFKSDCpcgLhuizhra33IBHLkI/PbVX3D9ZXlavxsZxxadV6HsK7L2/jXqxUAqjxNzdngFZMxEcT2a8PufBSvDHd/ynNNieNtYLX5gn5wi3Yyij9KpvQdeTHYERLr74kvHNwpLJBKY5BKss+FxZ3iown0TC1SYgaOJ7Rm5ljx/h4Vx1TwSyvfSLWPWytbJPB4uNy1U=; 4:aAC7fO4wpLQPlWN/V14QSvv1bwciDXYFoPMIcPnLibvGMT8dr3Gg+wSAsgJ6zKe1gExwzzVJ+TP/OtvtY/CwkUHN7ApGZs04+YaLnzkBs+j5/jeWLMVV74RktPvhEk33ffwoaJHp7kM+1cjtwtoONoyVSxCTSGeQSXHwYHzUdoX0+4ShB0bg+ujsc27pP1W4yIhPlf4KLoU5zCClzRGk/kJYWovUgwL0IyasJBz0U1ujsqBtEdcxddvKSzkwngT0kNtW78r8VhMQ7dD/G/QVVkQyrczIsyFCQoUeSrIbk7CVVJF2S9+p7vWJdwHuKUCH 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)(3231022)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(6072148)(201708071742011); SRVR:CY4PR0701MB3635; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR0701MB3635; X-Forefront-PRVS: 0518EEFB48 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(366004)(376002)(346002)(24454002)(189003)(199004)(33646002)(105586002)(106356001)(31686004)(2906002)(65806001)(66066001)(65956001)(316002)(47776003)(53416004)(15650500001)(6486002)(76176011)(478600001)(52116002)(69596002)(55236003)(2486003)(8656006)(31696002)(83506002)(6506006)(68736007)(6116002)(3846002)(53936002)(67846002)(2870700001)(52146003)(72206003)(23676004)(6246003)(5660300001)(81156014)(65826007)(6666003)(2950100002)(8676002)(6512007)(8936002)(53546010)(64126003)(81166006)(42882006)(97736004)(229853002)(93886005)(59450400001)(16526018)(7736002)(50466002)(305945005)(36756003)(54906003)(4326008)(25786009)(110136005)(58126008); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR0701MB3635; H:hyd1ajoseph-dt.caveonetworks.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTRQUjA3MDFNQjM2MzU7MjM6VFl4dTJPN0hZc1FmWUJHT0cxanQ1cFZM?= =?utf-8?B?VFExbytYdXFGRFJ6QzQvcWNWZGZmbUgrT0ZQNEw5dzl5ZnRTR2lUVVBnWWxT?= =?utf-8?B?ckhTWUwwQ0dCUXhlWVFNb2xZU0YwMC9IWHkvZXBCNGtORWRmSXRFeS9GYkVV?= =?utf-8?B?Y3BXZkIwMTlnTTgwN21aN2hDVnBVSG0wcjZUbWhxekdXb2ZlclVTcjk5U3NC?= =?utf-8?B?K0w1b2F1d2lmVmFJbkE0MnNqWTJ0cm1ieWZVdXhKNWNnT2V3SFhlZzFQMGJm?= =?utf-8?B?UEtmU2hMaWQ4L2Z5T1V3RzJNTFZmcEI3a0hEemVTT3JiUFRjRFNpYkRzcHU4?= =?utf-8?B?RWZraGJ2bTU3aFF2a2t1M2RrcFJxdERRZGVzOUl6ODZyZFVVMklINW9wVDZC?= =?utf-8?B?bFRKNTRKUFBibndGcllPNVZ1U3p3RytRSVBidTVtaWlYbVNmYm5xQUpiYnBE?= =?utf-8?B?TkZQM04xMVZTcnRJWEVSZVJpZXMzem10Zk1mcittNGFCTDFaSVFVeHMvSmJZ?= =?utf-8?B?YkIxSGQzYk9TYnRGTFN4ZVN1WG9JVDd4YTNWS2JmektmdTVvZlN0cFpJaStu?= =?utf-8?B?MUFhaUdHeVkwKzdhU3JWdk1IRFlQRDBra0gzWStENnFGc2kzWjM2b1RNVm1h?= =?utf-8?B?d2dCbDhEL2F6VTVXS0ZONmpDVVV3a0ZjNXpHK3huSlhiTjZTcFFWVW9EVnVn?= =?utf-8?B?V05sVFFQQVB6MEc3QXhxZThKYnJrVkducHVGMVZjMDFOUWQySGhQMDRDMDM4?= =?utf-8?B?d0tWVk1FZWl4NU1mM3czVEVNOWJ2aTI1bmd3cWdBb3BjczFFQW1vc0wzdWFz?= =?utf-8?B?T3JSVXg4MGpRa2pua2xOV2dGY1Q4ZGwrK0lwc0JXM2RoU1JKRFZrK3krd1Iw?= =?utf-8?B?UlJWRnNqWi94aVYyaTFUajBuZjV4bUpoMDdDWGkyZDNpTnpma0lHYVlSclpp?= =?utf-8?B?dVkvZHQvTTgrZXc4V25sRThJZk5veFhER2lwT0VNZktCa0dnTFVPM3VpUFY0?= =?utf-8?B?ekZTdE9yb1FSdGlzazl4RVJMQ2JNTzJIeXFLUnRHR1g2SHRlQ29hQy9PL3NX?= =?utf-8?B?NkVSQktaRmE5R1ZBd3Q4a2hhRHVsT0tYemhQZUdPU3NWYkdQS3FmcHZQVmky?= =?utf-8?B?cDREZmszV3hGMkcyMTRzTk9jV29GcEZrcFpWMkhmZVJ0VWVnSkxLYTZ5S1Mv?= =?utf-8?B?TFpWU3FpRCtPUW5ISlBrVnFkRUZVRjJ6Yk5CQUVXc290S1BCcEJiQ0xqeTRM?= =?utf-8?B?WUlVM2VySzc0by9SS3NaVWQ4dThVRkMwZXhEVDJDTVd4cHRvZDFIOGJyMDZX?= =?utf-8?B?MjM1TWo4dXQxejFjYUdoMTZvenNteS85a29MdHNudFRMN3ZiT2lYZStHYzFO?= =?utf-8?B?bEQ5OU13K2x4UTgrTkltRm1XT0gveXhFcXVvNEZTQ2JJdVlabTZTZnRBMzl0?= =?utf-8?B?UEpjVU1SK3pEdm1xMm00dDJINjFnQ2FWWk9odWs1bm5DTUJweVZHTEVtOE1h?= =?utf-8?B?RmpmNUxReXFuN3FNZXJ5cFBibENZZld3RFlTUk1ObGRsNEkra2p4RHBaa3M4?= =?utf-8?B?bUNKeEpwY3gwM1VwdjRDaFp2d0JlYTJFLzgyeER0TUk4MUw2VGdBUDMxcGtu?= =?utf-8?B?WitDRGx2R2piUENYM2xQVzJOTyt5eEZ1am00QUptUTN0cFdGbkUzdlJYMmxh?= =?utf-8?B?S3hyYmxVMGx0NThDZVdvQUNJKy9JRFp0L08xbUtJdzduZStneE9XdVc4Wk1k?= =?utf-8?B?TFVwSXIvbzZyZGZBckZUY3FYbCs5TUhtZmU3Mk9ReW1qUEx4ME1mNENjZElE?= =?utf-8?B?cmFuVXhQSXVackR3aHYvZ0NDb2c4ZXpRRFY0SDYreTdacFZTOWcwa1FBVmZl?= =?utf-8?B?a2FZYlVHZFpGZERoalorY2tER2ZTRUN4TVIxRjlLSFppYW8weVJ4bThYcTdI?= =?utf-8?B?YjRtVStEZ051R3FuOGJEL3ZpL2k4bnNlZ1AxdU5uajk4T2V2QzhGUi9kVjhX?= =?utf-8?B?OUlqcW1RUzlma1NvOEJvM3lKWm1ZbmU2bk1QQzNnPT0=?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR0701MB3635; 6:dpSnFRMdOWdfSZR/EgjNKdZnjhCrETNLDTLnGktG2MRpK6StQ49efWzR1okBp5BnJcnbzLgPbZBqmrBKnnNBEwlOQpXzPdfVvqzYA3KkQMm9A4BhlxohhfwNY632YSXw8zEQX7kn112pwGDlllmUZj4kPU4i0KdsoWyDnPvcySBbB/0KoXBEe4ugoAvO5UjZg/YEo4kcZO9vp+F4dtwRg/A5v4EM83+sUM+/oVP6AXIjrGKP+Eqg3rgQDxLSInlqDfLngJd1yZl0xLs6FS3ahx/lspvXSIMzigP/99maDK2+x4Xxn2oSgWpDOxvNtRqh5DuJKFs7ooX7Fmg1qrx7JRsFgoGchzzDguFmEGaBUW8=; 5:wpcHwkMClZFcd2A0spLQxvKiKq+9TOG/11ep4epj7dEh3DUy1/RgLUdPFUTLxN6fCW/cSFbimwlno00cwF7nfmISm31uRGjJq0We3OA7Tq3TLj2+LfdlqbNsGv+xYKZHdBxrYitEVu0ITZ4LHI3QNjqYzHxUYRzmcWSP1f7ChPQ=; 24:BMCHAa7E3OFUrK5+eYb5h2E2/F6TWHLJbH3vKSUU5yZnF4WkNjLH2gwfhlyJKA9deZlW0lvdmGPPKgiMsgnmYRHyHvnqabWXKzxs5eFaFzw=; 7:Cv6FO3OxEbaWELBqa6JsXL2UJ0TjVl6G1qeSTb34QMRTeisTQlvJmciKL65AVMhT9rJDWYssqoAGQWUMZvw2VeD/DJVsXECeMCnlVXL9zSsQ+RxvdwtpxZSWH7yjTSTZUYP9DZR00iduLLXOprJvJU9+WOiCe2A6qeX9vJpGJD+Mw4/Jwjgoknvl+5sQqETcyTgsMGWR9bcfaF3cnF2n34NYRXQTOoqpQnddLj3OXtDb/pWUNUvG/4tffn+K1C/S SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Dec 2017 07:21:51.8988 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e4376898-3e25-4699-52f2-08d54067daf5 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0701MB3635 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, 11 Dec 2017 07:21:56 -0000 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. >>>>>> >>>>> >>>>> 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 >>> >> >