From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0084.outbound.protection.outlook.com [104.47.34.84]) by dpdk.org (Postfix) with ESMTP id F048F237 for ; Mon, 4 Dec 2017 11:16:36 +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=2qFSKm3SobZdHmSu+VbwiHYgi9W/sDtyExDal4kWGs0=; b=SpXVKiHqGBWStzYNl/n1Odew0OgtJePu03rsqpCiKccwS/Z8WAAb7ILtJAh7zDosyUX0A4yg4YPTYUaPCDBQHaCLDHMtN6SCIl6YsS3wy3EBQYYbFmIfocMGeqCy9bSWj6qkQq5ysumb/kTCTOQce76IhaBjXx8VRhXi0M9BmKU= 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.282.5; Mon, 4 Dec 2017 10:16:31 +0000 To: Akhil Goyal , Radu Nicolau , 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> From: Anoob Message-ID: Date: Mon, 4 Dec 2017 15:46:26 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; 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-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [115.113.156.2] X-ClientProxiedBy: MWHPR20CA0003.namprd20.prod.outlook.com (2603:10b6:300:13d::13) To CY4PR0701MB3635.namprd07.prod.outlook.com (2603:10b6:910:93::10) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 67b90939-5f87-4765-f906-08d53b001892 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(7168020)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603286); SRVR:CY4PR0701MB3635; X-Microsoft-Exchange-Diagnostics: 1; CY4PR0701MB3635; 3:IHnRggVrNbHi113MDKaiHbL0dYXrlbingrDwXKc8s7zHgjtSUlYELDeXceSrPZ/6UQdGk7cY7TlucgN41qv8AsK+mC/qKGsdWGd4IreoziUWm+Ov6jPFgk2FT9Ww5c5NQQw63PBZhOQdKJs9nOOV5QzxlYurU1Wb0nsnTR+neNeMshx/i58AheS4pC7apGgR+nt/+CIVW5z80wd33Qc2QJvyMhGw317pBcV1nWt2/UN73v0Gcul1ycLidUtSKV18; 25:/5t3zzP9YYMNCQThzfb/LluwLKNnsBevxAFHQ0/y+hHGSxtM7PS/+uhbBAVpDgw1DRro4l89TXrx4RiDh9YvrWsiYj8eTaWvxDZxAhtHQM3o4ESxj1j0axxbpi+V+vW8ved+5aibrIQJDc2176FXEWHIs+B/AVjEHdxGIiVZqhS4XwxSPPahfzu3pD7qq73H8j43Hvr6meV2hzYWupeLSL0kyvob4cAY5NQa4sJPpMcaObCi3emb3jem85U0F1k613SDZHOTMDklio9kTVamu0zT80vBXNA2pnm4MtAC2Pc/Gmvm7JcFlDQYZeqiR853ee+a13h9TW7UOg8YXENS3g==; 31:x4CkYgmasWAEpdG1BZxYoKCU92OJpNbpTvI9cjzAbiJfJl7gFQ+DDCTc3n+ghit/gtxBXxUh7Yvay4hYSwUNc3PJkewZPlexRHg+8GwuT37o1ThsI8DymrNeTdhSE/4G6LRqcOO4/ed2Nb6x9nQerfAADrWSG5TYXflGI/CPDdbHk7S/+3GKCCddsYjCc7nT110e/7O0lh8kg8mTASjdccysiU6mHTrOhwNrbS7Ut9E= X-MS-TrafficTypeDiagnostic: CY4PR0701MB3635: X-Microsoft-Exchange-Diagnostics: 1; CY4PR0701MB3635; 20:Kw1sGsibjKjojMbU0bvZW5YmGNEwzmrcOR3iOLlw6Cbx3RrYyHHuNrxJrIQfd9DjVEUFga6a9aIndciioOn/9Gu0Fh/uDXYdZIndSwEJEvRGRW8Rd7Gk7Kgm7wPlc4CXH1+0On+xMKMEkM2wvT+YzioGaN8SrZoGTAD0eE/Dc6gP9ofG0vsQz/5ifA88jI8NF3xZSoUmOxX6eGlITqwriJ/5Rfsqbfm+HaKVp4zCCliafoaIQC68GxbuYxoLxuG9uJ/GbghNryO6m8vg8pFffeo7y1pmn4g90sqtPosQ7aebbrvCl/OaN+fpFV/JU/4+Pa8QKauy31KaaPSFtLGaVyeNSUj3Zj7mN7bkOR/ELc8SxJ0N17qJN0PWETdK9YfGzKVJp+74F8Uicmwh9TP/evAbm4z+oKGCFZzrHDiY92yzTARMSDIFJe/kUvQrX8vHRFwKDMZ6cYXggmFasc5NYbVegtntElG5H/q1dC8intcwC3QdgL0Qq7OQalesUOxpLdZ/W4BTe7Kp279VkqTzt168/rUotr9jcNX15VyYOmJEJhPJlYKTJH7GRKoBDBPze6uafr6k97n5AyHzhCjPrprYZQcvRWj2kWAInkkwUqs=; 4:U2jjEHUqLvfoTEHosLzGau+Kj/jqxvOH0YUAeB0g2aFdlpqn+e+ClaTA/iL1HGiRk7+u252CI5lYjF1Xdx9mZ5k0IKbG5pME1egoWRc4E3Z8dt0rFJEf0QR4JednoFcu49FoUsahy/D1YL7rTwRFtGJVWEDi538TCDXRn6snaWH/5ZgsfKHsgXkf9zD3jvG4/H4OkAit6zdAc8qMO9X0BATQrJxlWIg+Gn7ta5/2RTtp8hGvkoQ5azToH95SOf6I0oUIoIlTWb7bdMsJACfXgH+XUuEj/j9nurbcF77+IE512SUVAtzdRyQlwMSJU7iw 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)(3002001)(10201501046)(3231022)(6041248)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011); SRVR:CY4PR0701MB3635; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR0701MB3635; X-Forefront-PRVS: 051158ECBB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(366004)(376002)(346002)(24454002)(189002)(199003)(110136005)(53546010)(47776003)(6666003)(105586002)(54906003)(7736002)(93886005)(4326008)(66066001)(65956001)(316002)(106356001)(25786009)(6116002)(50466002)(229853002)(36756003)(97736004)(3846002)(42882006)(2950100002)(69596002)(33646002)(53416004)(189998001)(6486002)(65806001)(58126008)(53936002)(55236003)(6512007)(6246003)(31686004)(64126003)(6506006)(8936002)(72206003)(65826007)(2906002)(31696002)(478600001)(83506002)(101416001)(81166006)(54356011)(81156014)(76176011)(5660300001)(8656006)(15650500001)(305945005)(52146003)(2486003)(23676004)(16526018)(2870700001)(52116002)(68736007)(67846002)(8676002); 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?MTtDWTRQUjA3MDFNQjM2MzU7MjM6UUVjRFg1MGNwa29YUk5pWS9TNGY3Q1ZV?= =?utf-8?B?eGpndFdzeWl1QmhzOUNwV280a25RaVBGblBpS2JneEFSUHBVZ1VlMElTY256?= =?utf-8?B?NG56QVVoZENsS2dublAyME1tbDJaQVRtOU9nQ0owVGFVd0tSbUJ5NGFwRlpi?= =?utf-8?B?M254cEw5TzZrWjNrb2xMR0o5bysvRi9yY21WMHcxUEZwUzB4aituWHp2QnRH?= =?utf-8?B?Qmp4dk0waEdFYkFzcHhYNjhQSmRNOGNDOUZYVWR1QmNVV2E4MTlodi9heFBN?= =?utf-8?B?MGlhRStrNUIvdmU5RFYvVkQweUhLVlZrZm9raW90S2dDbDFjNUlOa3YxQkll?= =?utf-8?B?RjI2aGVENkc2bWZHYlRmVms3OE9qZnc3QUMvVlp5QWVsY21hNzFFbXdHUXZC?= =?utf-8?B?bzdZcWpTS1BOaVFBV2dTdXplbHB3aFBsQ0pZRW52azh5RDlNL1lsMDhMcytP?= =?utf-8?B?aGJRbGpGclNYRnFzNERUQWdlanY1TzJ0SDJxL1ZxMktxR0wyUXZCT214WS9K?= =?utf-8?B?ZFFBckR6dXFOZEJ3K29NaVJnSzh5NDZxQ0ZPWnFlMlB6RGpuVm1nY20vbkdC?= =?utf-8?B?OE1GYkxxODNZQnpmd0dyai9CRVh4SWE4aFFCaXJsYXgrSldnZmlUMzNMUTFI?= =?utf-8?B?TlpBV3dzem1oYUFNN2NYU1h2VlQ2YW92RHBDeHdIeVRzdmxYR3hGS203MGlQ?= =?utf-8?B?T3Nzd2FQTm5ZZHBTYUZ5MTdIb0tGZ1BXQ3lXSmw0V0Q4K3k2b2lVSTZSczAr?= =?utf-8?B?RWtkbXB3ZG5DRXVoLzRDanVWbXphcTRhTEU3YitqbklaRzhpYlVKY2VUWHBZ?= =?utf-8?B?WEN3Y0hzUGEyN1Q4THpaaHk2dVVOSzNsSjNGYVQreEVxRHlwZm5SaGdYMW91?= =?utf-8?B?c3ZCUHlHcXlxb1Q3RHd0QWdHZ2JzV3ViYVJGakF6ZU95ZkhxcFJESDdIcVdt?= =?utf-8?B?UFk3OXRtNTdNV2pCQlNtdmtTOXpSSGd1RWNaR0tmbjBPMnVhdkNmVC92bUkz?= =?utf-8?B?OWZCQXlHNWNpb1BFMVhFKzEyWEFleXVtdlRsNS9vdGZ1cWRXamlaZStOL01B?= =?utf-8?B?TzZ0UUFhYm1GVzlReVNhY0VSdTBnaXpzcnpoRTNvbFpLcFBldW51ckMzVE4v?= =?utf-8?B?cDNCdkhUcVhaVisxNncxYUpBRE93YTlxNklFbjFTNklwM3hldGNYVkVWVGtH?= =?utf-8?B?bTdpWm9JQ3hZRDJtSEhiWUtDYkhPaDRTd1RwQVhxd2VwQmo3bWpyRCtaaUZF?= =?utf-8?B?bTkzbGlqUi9VaGMzdi9lcDhpNGltUHRwT095Y0lYZFE5MlhkQzlWK1hYUXNO?= =?utf-8?B?ZVZIbC8xTlY0b3VQK253Y0lnVmRwRnZsOHRlWmU5d1lyN1pLN1U3MDV0RzB2?= =?utf-8?B?UllBenhUU2JwanUxay8vVG5YZ1Rlb3Y5OWxocVdBSlVvTEFUZ1NZMUEvYlYx?= =?utf-8?B?OEdqRXBod0ZiQ3Q4TTJhdWtLRGkxeFEwK2M2dWFTeGl6NUg5RlpGbVJaZnpj?= =?utf-8?B?Qjc2RWc0ZTVlUHBIMGVRVTNEZ1hqMFdKZ2xxejR4d2p5RnY1dWw3eXJxeU1u?= =?utf-8?B?SlBwckRTMVA5N2hKNHl3MUZ6ejYwaWtMWGZGM3pzN1dMbXhpSFlXU3JhYTgr?= =?utf-8?B?R2hkWEV0K1BPUXJCTXBCSitQMCtGUjIvbC8zeWhqbGpRSHZVQm1LV1g5aE9k?= =?utf-8?B?VkJqOExTc3kyR0puQWMvWCtvekdkZGVIREZSdkRXWHAvdWlhVjFWOGtKSSt0?= =?utf-8?B?VDZqNHJHSncwRUwxR2dnS0kveEZmK3hCbVJDVnYydmxnZTB3R2xIYW1qeUJF?= =?utf-8?B?anRMTDgwYTA2MHUxSkRiVVJaM3dzN2xhV3hxU1o4dGZmR1hoOEN4SE90Y200?= =?utf-8?B?TDA4MGJlSElSayt1bUhpa01ZUktDTHFiN3Vudi9wdk8wVHV1K3puSkVtZ0tL?= =?utf-8?B?VGEwbWoxNUFQcG9Cakp0empJT25NMGJnTkJFcDk1bDhmRmZkWHRMaHIzTmE1?= =?utf-8?B?dXIyOFk0Y2gxdzk2djBuNUpsVGxnTXpXSTNCNlU0RlNMTWg2bWpBK0N0NG5U?= =?utf-8?B?Y0RlQnpESjZtZjlNU2ZLdXNMcUtCNDZ0dGtVTHNGanQzbU1YeTkxMmV0U05S?= =?utf-8?B?Q3NVdz09?= X-Microsoft-Antispam-Message-Info: kmJtJznrmBFO9u77luNylT6rSE7c0jNbv7i7AGQKw3yCJDFq+eZbIJRvyUMKGJZxf2LJYEKEIyJDP/+mSDTmJA== X-Microsoft-Exchange-Diagnostics: 1; CY4PR0701MB3635; 6:gRRT1BlbNSVEKPs+vmoODEkzPN6y5ASTZ8cQRiQ/CTfUGmAjTmFlI0QxGXvVVeGKUW8C420d0tTljcz1DXtOvmWwTPi6ai2PMT1WTyen12hSaFkDS1HJYO/u8cMwIMc2pANIwNegdqhpcg4mNZtzMqAlhbc6TJKMpGe4f+ipqaqoccBcmoD0OJqmIjWMvDuTq7kfjGaeKunsIEh0q8gqmIdl3+AYfX7zKEuhRW09tNTXfPUue5WkgHgKGcKBfHWdzwmgeriB/w59hCHlce1Y10BYbnADsFslNnKJFIQ/Y4ZRt7bTTtsc3lGY9h7XJgW4kRRhdqspmaMFrC0bB0QfrsYEDguwIUZpQK0c15ytftA=; 5:noxHdcZ17Bs2LvsyY8yk+bdAv01gVEPYmfDcqBI2Qm2hgH3ADannekV1SifxqIVuWIXqt2xzI4LSU9mOojtMsycAWbTg+2FsiRguMiqVjq3KCp85gcZh8VBELy6jGdS5jIcTwjkncu9NVGTIO4j7vwutDhwPbFK1xzH0AZwXaJg=; 24:Py1LpqZlURXWXLYLVav95JyFpULr7oZnksH0Jcsy/jdVgYe0cSKkXD518G8BoNwcQDlQN3ciYw8AEhn7KT/PcXlOIR7/3HMoEii4GGtzsEk=; 7:kvCKUF0Ga+0xgFlcIfVp0p4RMhVNI3oGQQGLC3wFwZnrRIU3K0t5YqxivU4HbiKFoe4PI+6c74j4k46IbG5Eqn7HbYw82Y1hXUF/3louBd4ou19hYzLfdugltSD5XYOBt2uIoy0ZaCSHnlJZXB+xi8yaoXKH9Okfd/rhZ44ClRggoDIWsdETOd9t6we6/iEVUKVHZ4o8sYWYW5lDtv1KuaoLjpm+N6z/xd4SmgZRu3Hwka9Argxp0E15O5qmM+JR SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Dec 2017 10:16:31.8616 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 67b90939-5f87-4765-f906-08d53b001892 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, 04 Dec 2017 10:16:37 -0000 Hi Akhil, See inline. Thanks, Anoob On 12/04/2017 02:58 PM, Akhil Goyal wrote: > 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'll update the documentation with this behavior and will send a new patch. >>>>>> 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 >> >> >