From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0059.outbound.protection.outlook.com [104.47.37.59]) by dpdk.org (Postfix) with ESMTP id 365281B017 for ; Tue, 16 Jan 2018 13:00:31 +0100 (CET) Received: from CY4PR03CA0106.namprd03.prod.outlook.com (10.171.242.175) by BN6PR03MB2691.namprd03.prod.outlook.com (10.173.144.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.7; Tue, 16 Jan 2018 12:00:29 +0000 Received: from BN1BFFO11FD035.protection.gbl (2a01:111:f400:7c10::1:100) by CY4PR03CA0106.outlook.office365.com (2603:10b6:910:4d::47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.407.7 via Frontend Transport; Tue, 16 Jan 2018 12:00:29 +0000 Authentication-Results: spf=fail (sender IP is 192.88.168.50) smtp.mailfrom=nxp.com; intel.com; dkim=none (message not signed) header.d=none;intel.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 BN1BFFO11FD035.mail.protection.outlook.com (10.58.144.98) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.20.345.12 via Frontend Transport; Tue, 16 Jan 2018 12:00:28 +0000 Received: from [10.232.134.49] (B35197-11.ap.freescale.net [10.232.134.49]) by tx30smr01.am.freescale.net (8.14.3/8.14.0) with ESMTP id w0GC0OuP005176; Tue, 16 Jan 2018 05:00:25 -0700 To: "Gujjar, Abhinandan S" , "Doherty, Declan" , "Jacob, Jerin" CC: "dev@dpdk.org" , "Vangati, Narender" , "Rao, Nikhil" References: <1516017078-166766-1-git-send-email-abhinandan.gujjar@intel.com> <5612CB344B05EE4F95FC5B729939F780705FED56@PGSMSX102.gar.corp.intel.com> <5612CB344B05EE4F95FC5B729939F780705FEDDD@PGSMSX102.gar.corp.intel.com> <5612CB344B05EE4F95FC5B729939F780705FEF35@PGSMSX102.gar.corp.intel.com> <5612CB344B05EE4F95FC5B729939F78070600131@PGSMSX102.gar.corp.intel.com> From: Akhil Goyal Message-ID: <0ed584fb-3524-0a52-44a4-a2b1759ecfff@nxp.com> Date: Tue, 16 Jan 2018 17:30:24 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <5612CB344B05EE4F95FC5B729939F78070600131@PGSMSX102.gar.corp.intel.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Matching-Connectors: 131605776289876764; (91ab9b29-cfa4-454e-5278-08d120cd25b8); () X-Forefront-Antispam-Report: CIP:192.88.168.50; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(39380400002)(396003)(346002)(376002)(39860400002)(2980300002)(1110001)(1109001)(339900001)(3190300001)(189003)(24454002)(199004)(13464003)(356003)(305945005)(2870700001)(2906002)(105606002)(5660300001)(68736007)(4326008)(106466001)(31696002)(65826007)(104016004)(26005)(229853002)(6246003)(93886005)(23676004)(8936002)(67846002)(2486003)(77096006)(316002)(97736004)(53936002)(64126003)(2950100002)(50466002)(53546011)(76176011)(8676002)(31686004)(81166006)(498600001)(65956001)(47776003)(81156014)(58126008)(86362001)(65806001)(85426001)(36756003)(54906003)(83506002)(110136005)(59450400001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR03MB2691; H:tx30smr01.am.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD035; 1:7fzs4F2fCHnqLCx+KALzeGCQOdNC/ckgCT/DDlaBhrABV4Py53casqzD4gwZ/MiJXJ2o+YhwBUQRTUJSM1iZqlK0yUmj+WeWSI9WDhBuAapPvceP7+q3+e4Pi5qBf0zd X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 22a6b841-d998-42c8-cb1c-08d55cd8bc9c X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(5600026)(4604075)(2017052603307); SRVR:BN6PR03MB2691; X-Microsoft-Exchange-Diagnostics: 1; BN6PR03MB2691; 3:pfsf4S4g54VVKJeF6cTo7GR+SkitvWP2nqU7RrN0Q9BGCEmAWQs1cN58Q4MvqYuXAObIgJlPWnOdWBEUFUqDsIv0+Npgh8+S1pSPtbHrqci5rESCp/XShCQe3TLjuWq0iG4um+ZNouoN/mNhl8VJ7Zue3NlzUUeSOqZjtp+BN5SC2EjPwTqRupNPoyCaorniwkkntjmlDn6Pgz/ZyvqIoEbadbDHSC+lBMbxzsvcB7EW0FOm2BpBjYw7DZ60O+aewiDODAa2IhXHPwYLo/508YKPSKuKebftk96TEx43mhWyRZHttzjrt25GauX3RefAK9Ny3inNfmdbzfFj0RduvANPhFqomUwu9NXBGT648V8=; 25:Lc7Lrc2ktYHBWEW0MUKX6WWZ7rsxYaVGb3KbQI0E/k0m6/yoEjzRz7q/0H9mBKz8J7G2Jl0xr6rejS2QMB+KknTyndM5F0LZXUUcAccWBn5hfGavI32UA8m2GqiTjHtrcvBiLJiLPcTXZlD+7pz/vBQoAsyjW5OpaxJB5M9dekWvKEwVykkEZ8hKvyP/rZxy1Gisgi2hck3vxNhzVEPTdwZtT2VbUPNzeqbsRBjj7tmKXg10SB5SMx4mLlB0UBwCeGm7OEx/hGGa2HVarKNIu/WdA1KVphaUev6r+PUmpV/2iPl1UXhCKoScriYDmGKKV9y8fUBtXP5SJ/vEt9gY9A== X-MS-TrafficTypeDiagnostic: BN6PR03MB2691: X-Microsoft-Exchange-Diagnostics: 1; BN6PR03MB2691; 31:98vU+JloLL8avgWtMcdY7Qhs+Zu+UhDHckyFQmN1EZxn3X/bALXAxNngR1nRlJs27QWcmzWB8t0QSllZfKllA13+JyF1k8rf4s8TSSd5CMNpm+33lBG9NE5vOeutk5JsoWQZKdWxBQfTyuE9Zy+ddHnVjsZErpAW17gfJTNt5p4+bBY1Erh1+BJml/T50/T31HYQsYZP+x1p8Bsf8ig1wTjYEe6ggXtzpUPpfivazmk=; 4:qfwYH9VwK21HN0Xuy7xzHM56qhWc6q3sr1n3seKZrwuAfONezCB9QpVRVdd9hJqwIQwL+n/Z0fAjdIAYh/udhRIJdsbIqDLyOGZM+TIq+BoG3RaKiVeygBGOTIY6wNp6KEqC8EXRV7dMA94IAVBd5ScpRrWP0fnz0TQeWWODa+rs+Lq8WCzK4Czee/eG+Cnw8Y27iaCKJR1bMBi/m08PedjmVPnd3sbxHbIb7FkW347RWVdtD6PGyVZ7gaaI+xO/Qr97NOyZKuKgsecXnFjgsHOeCMcGD6g8sKKcHTMtNNGaXDydazJQ47VfAD8l1h0HNOgU49XRJ+FBkGf2xjigwSphSTCmZ9piFmbohe2D7JoLloJ261CwkhhJU6ea4Hxv X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(185117386973197)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6095135)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231023)(944501161)(6055026)(6096035)(20161123561025)(20161123556025)(201703131430075)(201703131433075)(201703131448075)(201703151042153)(20161123563025)(20161123559100)(20161123565025)(201708071742011); SRVR:BN6PR03MB2691; BCL:0; PCL:0; RULEID:(100000803101)(100110400095)(400006); SRVR:BN6PR03MB2691; X-Forefront-PRVS: 0554B1F54F X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjZQUjAzTUIyNjkxOzIzOlhtNTJHbjhFVVpLTjRyemFWWURMQ2ZOMGpp?= =?utf-8?B?Y2ZGd0kyLytFdUFtdjB3RXhCQlZIbnFpZmx6U1FSR28vR2NoV0dreFFVYk9C?= =?utf-8?B?R2hQRzVXbWpsQ0VyWGNjNGdCcjNQcFNJVld4ZTBTK0pGbDFRMDhzV1dzbHlE?= =?utf-8?B?RmNMZkh1cWZwM252Uldna3Y2ZlYyZEtzeGhMdVRNRU1EUkIzWElEZXp6dDBR?= =?utf-8?B?dG1qOXBFc09UazFzOTk2S3lseDI5SjlJeFBWelFaREE4UGZ3cVl5bXJnbmJN?= =?utf-8?B?MWNmN1d3Zm16akkyS3gyM2J0V3BUNitISVNiVFZWNjI1YlJieXFYc0xmdXhL?= =?utf-8?B?TDcvQXBianZMTHBCN004RVUzWUhXRytaNUZDS01HaFZXSTRESW4vV0ZXdi9K?= =?utf-8?B?Uk03V1hHU3QzcGVoUk1iNkIrRmFJTVlUWkJlNHR6WVlhVjYwUGkzQkliOHEz?= =?utf-8?B?bG02akpBUkp4Vm15bGFBSnNZUUtrYTloUWdmR2c2T2grVUNvRGpiWmtacTF5?= =?utf-8?B?UldVSG9wZU5jY1NHYmFWZjRkakIzVW0vcEwxcllFM2JVZGt4cURtWVZyek9C?= =?utf-8?B?THhQL1ZUbW55SW0wdkhKRUlFcUlQM01kQ2ZVZ1N0ZERleFpyTng1YnF5VWJ3?= =?utf-8?B?eElGbkdqQmppelNVbHBNTitJbTg3MjVDMVg3NnBvYXgyb2J4OHRsdFl4cnJl?= =?utf-8?B?NzJxSFJhaGpTS0Q3NDVIK1J2THpxSHptd2NYZE5LODIwVUQzVnVuWlp0VTRS?= =?utf-8?B?bTBrUGRRTHJZak1Ja2w2ejhUYmR5K0I2Tnh0MDJWaWMxcGdrL1pFQTFkektF?= =?utf-8?B?dU9aU0d2dHhsQlIvNDYrdWxMZmpITk9aQnRJOTgvYTFJN0lHUlBndENjTllt?= =?utf-8?B?aFNCZzhkR0tTVGFBeDk5Q0tBVUVLVjQvSG5CMmY5U28rQVpCWndOM1kwN2RS?= =?utf-8?B?M0dEY1pPM0tjejFjTmg5UEJuNGg0VFVOVTZJeHJMY0hzQTlHRlduSUw4UmtJ?= =?utf-8?B?cFV5UitLL0x5WTFBZHU2OFd4bHZBNE10eStDaENFcmMrZFFSOFo5b1hIQkxV?= =?utf-8?B?ck5LYjJscEtXMEkwMjVFUmZBR1d4Tk1wcnNGbC9XZmdEQ0F6T2hVWjRidWNk?= =?utf-8?B?azVOZXJmdjRuT3E2WngwUlNJY0Y2RzA0VU41eVF5NWIzWFB1eWxHZW5iclJZ?= =?utf-8?B?L2FqdXBSZlVPbVR5OHZaWk9IWkUyMGNMZDF1ZFdLSnhYbjBaVTBzRUVGRWVX?= =?utf-8?B?YnluaEJIVjhvWVhqbzRNK1p6YThNNG9RWGVmWUUwYjhyYXB5N2dXSkUrYUoy?= =?utf-8?B?ZmgwWWdveklqTmRDUnZvckFoc0RUN3lGMHU0bXF4d2U3MnBEUU4rdml2VW9X?= =?utf-8?B?NVVWMlNWdkZUUnVUWlVMNkxIYTN0UmhuQlIwQXVnbkZVWTZwMDZ6TVdXR2Ni?= =?utf-8?B?cWh6dDQ3ZHlEaUR5aW9ubWFZM3JmUG1YN05DMnBQb0NFcHc5UmF2U09ZQ3pU?= =?utf-8?B?cXBvSno5WlJUWFI2NmJ1V0NOWVIremdINXJzcEVwSGpSS0YwVjRGK1ErbXB5?= =?utf-8?B?UFJuL1N3U0I0Zk1ySTVNSlJjSDJsVEhRNUltOUdZUnNlRmNzbGtTdTZ6Z1gv?= =?utf-8?B?MysvY05kRU9HbGJaRUZmVWkyTXhsdGxHd1orTXFEOFF5NWUxZWhuM2tyYVlT?= =?utf-8?B?RmtVUGZXQkwwd1BBcnNpLzUyZ3RMOWVPVmlibE1xT3Mrc2pLc1g0MnpXWmJW?= =?utf-8?B?Wk5ZZ1pRQlNwVm52b1lPci85WHMvYkQ3cnlDS0tPTDlieGFiL05jc2RySnZk?= =?utf-8?B?SktaOUFVNjRnanpLMTAvTDFURXZITUxGZkJkY2ROUXA1d2lKUFFGbEdZbmpy?= =?utf-8?Q?tnd0F5hn6KU=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN6PR03MB2691; 6:AaxpuASn0C6zXEuITHR1Y4NLHUX9dUdBVYUHUYo/TSK2xgJMRuyswhXmUFbG6EZSpRPpuxKjjT4XafoNz8ZWmvFMddfJh61/0y3xbU8GYfm9IzqRE7flhNTxyBTA9TDhrr+X42SXA6FWe9MdIpc4G9bUz0cRx6sDEWpe4CgnL/NeqtKkUWF28z10xqVU4V8IfaE7sT/8oKmOKRvm6Kt3Dj1p7ktomkDCZ5Llp2BSd5LFCqW0mLZE2Yfly5MiVwISfQPrN4ZZT61ltO0xfKSOxP4jtYrQI/Ugxn4iMB+E+UB4Brte5GEc+4EOZXJM9BdvLLUW5SEbcARfQo2i7M5B3P6gYJY7XE9Jb/HF3T7W3sE=; 5:D49WnXoA5kTbkyGOTUcFqKisCfeQaCFyI9v8wzHpDxzeiXcVOPqEbjLGrm4E+OXf/EckaQzDZQmitTUCpXAiqJPD8APmfm86FfV4vFLtKah681IUiPArrEVTOfcSEsQtPtQ0mLFoGa/MMHTBcaP9x7xD3qbDDvnRYAlokKVUhJo=; 24:l/FSx6xiHOfoN3BukWAu0wjgygc0Tm2XrGCF6eKj0sAleuZ35qKE5N9+kZFg8nARMaVjKIYWm1q5yMgqc3ByXO+p3NIye3uy7+sw0UObhvg=; 7:MArO8xqFmGMxkk/0czAVdH1GykWrhmXY1eIgPfbNjZQefYgQCeN897ZjjTby9RxV++GcmlGt9ZXwrRcM2idSnBlJghejPmDiZn96WwcwARovoHiYprV6YLo6+r6PhIJJ/p6SvQEzEI+62TEXxZDwemBJGajCJZkXWCjQf4TzLvAa+xDkPur+SfWO2u4BNL+zv+qK8uk/f7uDteUdCjxmhbUo0impqg4TXbV8lXgUKjd7bKMZLIWNMMljdP7h35xd SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jan 2018 12:00:28.7692 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 22a6b841-d998-42c8-cb1c-08d55cd8bc9c 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: BN6PR03MB2691 Subject: Re: [dpdk-dev] [PATCH 1/2] lib/cryptodev: add support to set session private data 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, 16 Jan 2018 12:00:31 -0000 Hi Abhinandan, On 1/16/2018 5:06 PM, Gujjar, Abhinandan S wrote: > Hi Akhil, > >> -----Original Message----- >> From: Akhil Goyal [mailto:akhil.goyal@nxp.com] >> Sent: Tuesday, January 16, 2018 2:52 PM >> To: Gujjar, Abhinandan S ; Doherty, Declan >> ; Jacob, Jerin >> >> Cc: dev@dpdk.org; Vangati, Narender ; Rao, >> Nikhil >> Subject: Re: [PATCH 1/2] lib/cryptodev: add support to set session private data >> >> On 1/16/2018 2:33 PM, Gujjar, Abhinandan S wrote: >>> Hi Akhil, >>> >>>> -----Original Message----- >>>> From: Akhil Goyal [mailto:akhil.goyal@nxp.com] >>>> Sent: Tuesday, January 16, 2018 12:56 PM >>>> To: Gujjar, Abhinandan S ; Doherty, >>>> Declan ; Jacob, Jerin >>>> >>>> Cc: dev@dpdk.org; Vangati, Narender ; >>>> Rao, Nikhil >>>> Subject: Re: [PATCH 1/2] lib/cryptodev: add support to set session >>>> private data >>>> >>>> Hi Abhinandan, >>>> On 1/16/2018 12:35 PM, Gujjar, Abhinandan S wrote: >>>>> Hi Akhil, >>>>> >>>>>> -----Original Message----- >>>>>> From: Akhil Goyal [mailto:akhil.goyal@nxp.com] >>>>>> Sent: Tuesday, January 16, 2018 11:55 AM >>>>>> To: Gujjar, Abhinandan S ; Doherty, >>>>>> Declan >>>>>> Cc: dev@dpdk.org; Vangati, Narender ; >>>>>> Rao, Nikhil >>>>>> Subject: Re: [PATCH 1/2] lib/cryptodev: add support to set session >>>>>> private data >>>>>> >>>>>> Hi Abhinandan, >>>>>> On 1/16/2018 11:39 AM, Gujjar, Abhinandan S wrote: >>>>>>>>> diff --git a/lib/librte_cryptodev/rte_crypto.h >>>>>>>>> b/lib/librte_cryptodev/rte_crypto.h >>>>>>>>> index bbc510d..3a98cbf 100644 >>>>>>>>> --- a/lib/librte_cryptodev/rte_crypto.h >>>>>>>>> +++ b/lib/librte_cryptodev/rte_crypto.h >>>>>>>>> @@ -62,6 +62,18 @@ enum rte_crypto_op_sess_type { >>>>>>>>> RTE_CRYPTO_OP_SECURITY_SESSION /**< Security session >>>> crypto >>>>>>>> operation */ >>>>>>>>> }; >>>>>>>>> >>>>>>>>> +/** Private data types for cryptographic operation >>>>>>>>> + * @see rte_crypto_op::private_data_type */ enum >>>>>>>>> +rte_crypto_op_private_data_type { >>>>>>>>> + RTE_CRYPTO_OP_PRIVATE_DATA_NONE, >>>>>>>>> + /**< No private data */ >>>>>>>>> + RTE_CRYPTO_OP_PRIVATE_DATA_OP, >>>>>>>>> + /**< Private data is part of rte_crypto_op and indicated by >>>>>>>>> + * private_data_offset */ >>>>>>>>> + RTE_CRYPTO_OP_PRIVATE_DATA_SESSION >>>>>>>>> + /**< Private data is available at session */ }; >>>>>>>>> + >>>>>>>> We may get away with this enum. If private_data_offset is "0", >>>>>>>> then we can check with the session if it has priv data or not. >>>>>>> Right now, Application uses 'rte_crypto_op_private_data_type' to >>>>>>> indicate rte_cryptodev_sym_session_set_private_data() >>>>>>> was called to set the private data. Otherwise, how do you indicate >>>>>>> there is a >>>>>> private data associated with the session? >>>>>>> Any suggestions? >>>>>> For session based flows, the first choice to store the private data >>>>>> should be in the session. So RTE_CRYPTO_OP_WITH_SESSION or >>>>>> RTE_CRYPTO_OP_SECURITY_SESSION can be used to call >>>>>> rte_cryptodev_sym_session_set_private_data or >>>>>> rte_security_session_set_private_data. >>>>> Case 1: private_data_offset is "0" and sess_type = >>>>> RTE_CRYPTO_OP_WITH_SESSION -> usual case Case 2: private_data_offset >>>>> is "0" and sess_type = RTE_CRYPTO_OP_WITH_SESSION + event case >>>>> (access private data) Differentiating between case 1 & 2 will be >>>>> done by checking >>>> rte_crypto_op_private_data_type == >>>> RTE_CRYPTO_OP_PRIVATE_DATA_SESSION. >>>> >>>> Consider this: >>>> if (sess_type == RTE_CRYPTO_OP_WITH_SESSION && >>>> rte_cryptodev_sym_session_get_private_data == NULL) >>>> usual case. >>>> else if (sess_type = RTE_CRYPTO_OP_WITH_SESSION && >>>> rte_cryptodev_sym_session_get_private_data != NULL) >>>> event case. >>>> else if (sess_type == RTE_CRYPTO_OP_SESSIONLESS && >>>> private_data_offset != 0) >>>> event case for sessionless op. >>>> >>>> I hope all cases can be handled in this way. >>> Memory allocated for private data will be continuation of session memory. >>> I think, rte_cryptodev_sym_session_get_private_data() will return a valid >> pointer. >>> It could be pointer to private data, in case application has allocated mempool >> with session + private data. >>> It could be again a pointer to a location(may be next session), in case >> application has allocated mempool with session only. >>> Unless, there is a flag in the session data which will be set by >>> rte_cryptodev_sym_session_set_private_data() >>> If this flag is not set, rte_cryptodev_sym_session_get_private_data() will >> return NULL. >>> I am not claiming, I have complete knowledge of different usage case of >> mempool setup for crypto. >>> I am wondering, whether I am missing anything here. Please let me know. >> >> It depends on the implementation of the get/set API. We can set NULL, if it is >> not filled in the set API. If it is set then we have a valid pointer. > The plan is to store private data after "sess * nb_drivers ". > As you said, if it is implementation specific, flag may be again required at > struct rte_cryptodev_sym_session I think my previous statement was not clear. My point is that whatever we set in the rte_cryptodev_sym_session_set_private_data() is a valid value when we call this API explicitly. And before calling the set API, the values are zero or any invalid value. So if application calls the get API before setting it with set API, it will get an invalid value(may be NULL or zero or whatever). > OR > If it is planned to store at PMD's sess_private_data, it requires additional ops > as well in rte_cryptodev_ops. > We wanted to have a simple design with minimal changes to cryptodev and security, > that’s reason for existing design. > It will be good, if other folks chime in and share there opinion. > This will make the implementation part more clear. >> >> -Akhil > -Abhinandan >