From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0068.outbound.protection.outlook.com [104.47.37.68]) by dpdk.org (Postfix) with ESMTP id 037F11B2A0 for ; Tue, 10 Oct 2017 14:17:35 +0200 (CEST) Received: from DM5PR03CA0026.namprd03.prod.outlook.com (2603:10b6:4:3b::15) by SN2PR03MB2368.namprd03.prod.outlook.com (2603:10b6:804:e::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 10 Oct 2017 12:17:34 +0000 Received: from BY2FFO11FD014.protection.gbl (2a01:111:f400:7c0c::137) by DM5PR03CA0026.outlook.office365.com (2603:10b6:4:3b::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7 via Frontend Transport; Tue, 10 Oct 2017 12:17:34 +0000 Authentication-Results: spf=fail (sender IP is 192.88.158.2) 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.158.2 as permitted sender) receiver=protection.outlook.com; client-ip=192.88.158.2; helo=az84smr01.freescale.net; Received: from az84smr01.freescale.net (192.88.158.2) by BY2FFO11FD014.mail.protection.outlook.com (10.1.14.76) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.20.77.10 via Frontend Transport; Tue, 10 Oct 2017 12:17:33 +0000 Received: from [10.232.134.49] (B35197-11.ap.freescale.net [10.232.134.49]) by az84smr01.freescale.net (8.14.3/8.14.0) with ESMTP id v9ACHQi2031200; Tue, 10 Oct 2017 05:17:27 -0700 To: "Ananyev, Konstantin" , "dev@dpdk.org" CC: "Doherty, Declan" , "De Lara Guarch, Pablo" , "hemant.agrawal@nxp.com" , "Nicolau, Radu" , "borisp@mellanox.com" , "aviadye@mellanox.com" , "thomas@monjalon.net" , "sandeep.malik@nxp.com" , "jerin.jacob@caviumnetworks.com" , "Mcnamara, John" , "olivier.matz@6wind.com" References: <20170914082651.26232-1-akhil.goyal@nxp.com> <20171003131413.23846-1-akhil.goyal@nxp.com> <20171003131413.23846-2-akhil.goyal@nxp.com> <2601191342CEEE43887BDE71AB9772585FAA4E58@IRSMSX103.ger.corp.intel.com> <15007bf0-d263-05a0-2009-31210f686085@nxp.com> <2601191342CEEE43887BDE71AB9772585FAA651D@IRSMSX103.ger.corp.intel.com> From: Akhil Goyal Message-ID: <0d5a9ca0-34c2-f020-204f-b1105f357bdb@nxp.com> Date: Tue, 10 Oct 2017 17:47:25 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <2601191342CEEE43887BDE71AB9772585FAA651D@IRSMSX103.ger.corp.intel.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Matching-Connectors: 131521114538478885; (91ab9b29-cfa4-454e-5278-08d120cd25b8); () X-Forefront-Antispam-Report: CIP:192.88.158.2; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(336005)(39380400002)(376002)(39860400002)(346002)(2980300002)(1110001)(1109001)(339900001)(3190300001)(13464003)(24454002)(199003)(189002)(377454003)(85426001)(68736007)(69596002)(86362001)(498600001)(54906003)(36756003)(316002)(65956001)(110136005)(23676002)(4326008)(8936002)(97736004)(230700001)(5660300001)(2501003)(2906002)(31686004)(53936002)(83506001)(58126008)(50466002)(31696002)(7416002)(15650500001)(189998001)(6246003)(54356999)(76176999)(33646002)(47776003)(93886005)(2950100002)(50986999)(65826007)(104016004)(356003)(305945005)(8676002)(53546010)(65806001)(106466001)(77096006)(64126003)(229853002)(81166006)(8656003)(81156014)(105606002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2368; H:az84smr01.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD014; 1:+gZwxTCc/XyJsE+fAWVIgg5GD0Sj0bff7nIYqoDEDnXLxcLeh6Q27k2fGgvN9uPSSXahFt/4BcIR6ZuqxE2Zkh0iUscrmEMHHSxABjKfPM3twKvsoSVhl+KhMdqF+k/o X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8d977379-4111-4db9-20bc-08d50fd8e2e9 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017052603199)(201703131430075)(201703131517081); SRVR:SN2PR03MB2368; X-Microsoft-Exchange-Diagnostics: 1; SN2PR03MB2368; 3:EUdqsmfneTcvZYRk99Dd+QE1zDzlb5QGJgwZVfsIr+8Gh1/qPLD7oTEC4mmE9UGyCOYpdApUtV+k2ivOjiH82RRk5xnB7WJv+nq69nQx43rZBr37b6jtD7vxWGTaYad1ILrqmMrrvPWMRIJz789Hnr9EhYdq+M/ySpwUxo8+gkRY25+NayJPRpp4GuPOVW+/DYr5t7EIQlGBgrFpsCR3xx3Ax3qMgOhQZ8hTD45rYBieczoCX8HjH9mG1UK9O6Zkhy68SvJYQLOGdfl17ws3EGSPULyxwiSd8LYk9VTJi7fhzRcXPuWUeebeIR8A0uYE+mYQS/4cOroSVcGOYN5e4rgr2ftK+BdzJklt29wdkqE=; 25:r6EBptpsbFYBZ270w7TWlK5EvdgAXVqvehQ9fQ5RpZ+8UE/915z9uXjWtZeSAJQuVacQ0pdGicrNaQ80sDzW6TLwYcqW3b/glGr2Wje1ypdYPKbV0bay3mgMsBl/eUtP6AWXYMdhqUXzzsZU48j5f7OaMAr/SbRGReTnKmxYUr0MciS+DVpbaAZ9NRO4oKMd4HRywNC6oSVhjT2czVcYNNBAurW41TbvX2mZ3vaRH7IsWqLMJ0sKglZsfT0hxGbLp7az1mS0kClIVVPeHP/imXqHrEOeDfiaXCkwxEyH4PDTeKOPJ36us7kcX7IbvkVlUQ1kJFEvGIs3PNZXrQvYzs5SeK/OzpwmhKcqc7VMyhk= X-MS-TrafficTypeDiagnostic: SN2PR03MB2368: X-Microsoft-Exchange-Diagnostics: 1; SN2PR03MB2368; 31:/MfJ7paWuGeONEhSn1WJ5cNXzd4Ws2XOoD47vMMfBz23E4lBwxX57QYRbto5ecnNpl1Y1QiHMlq8hTpOyCnXexZjLNyoK3GAvFNq8SkZHpOX9hdrI+XuJK0GFOU8umLkOeK+kf/kqJ0ePAHH7AjbSs4adQD/hJxweVfYbRvVT4tCAHfgJfJBdxrXmrvuH6JHA0Eps2K5b4IoaboYl3Ueum/zbrrYb7Sm7H5EpaAF9Rw=; 4:yuCg/bVQmRHDMIyjrSoZgFkuReC3RPZXNXUfwXC44pQVSmZ7qUGXSkRh+aOS9Lf0Qn72Vr7Un08JeF/716P5v4NU3WRDQ2aU+y3/HdKUzazW97Lmg8gpBHwYx5iQEtLnmT+y7XpdPn5ofNQg6x84ClRwSiNvwMrOM1/98xTRfJ9PqenYDPg3F4ydAupwE8D2noo8ukA5TvyN7lnXqFJNE+4MEzSoQdQT4jXxPIE/ugDgU7fnp7X255IV2+MiUvffXTfuDbIqk5dEiVe0GAGSSlcM03HsS8wanv0RNOEHOTULYXec4yunLUHjmvKRKVZLJ1cfwJzxOELwbdQD89qbBci4uiRfQ4woi8HljwRtV1iS0Hz1+esNc7ZZSbgIm6iznBNV5R/QwqD7OZ7sue1X5Q== X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(185117386973197)(228905959029699)(17755550239193); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6095135)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6096035)(20161123563025)(20161123556025)(201703131430075)(201703131433075)(201703131448075)(201703161259150)(201703151042153)(20161123559100)(20161123561025)(20161123565025)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR03MB2368; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(400006)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR03MB2368; X-Forefront-PRVS: 04569283F9 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjJQUjAzTUIyMzY4OzIzOjlZaDFEamJLL2J6TGN0bUFrZ1Myb1lvMysx?= =?utf-8?B?M3VDMXl2WVYxWG55VGpyWjRSeGtoSnNrY1krRlBmSGhNZjBQYlQwbFB0eTNy?= =?utf-8?B?Q2g0RWo4Rmh6b3VJQUtDNW1iZSttUTMwWGhSVGNPZDZBTW9MZG1tYytzWC9H?= =?utf-8?B?WXNRVUJVZHkwdGxWandkc0NVWGgrbmFUUmtHeXRINWtaam05QWNacTVCZi9K?= =?utf-8?B?Zit3bE9haGpGTkwydjZiY2p3WG1jenhYdEZhalQ2Y2dWK1U1UmdzazV0OVdJ?= =?utf-8?B?ZFhhckhXRXFsTFNmODNwQ1Y1UjZaVXpEd0x2RnVrNVR6TWRwbEM2OTZiNlZJ?= =?utf-8?B?d1V6NzdkNm5oR0FzTW9uWXpmdlkyU0dwWEJQRmxLSjRaQW1oZUF5ZmFVQSs3?= =?utf-8?B?bWlXVjMza1ZVamJtZDRGNmErK2JvMjhtU1Vsc0VUVHpkS0x0M29SenYvaGM4?= =?utf-8?B?VGtrekZaZkxnREtzRzZRSExxUDIwNlBuNWRkNCtMaG9vZXhMRmxydW5OdFB3?= =?utf-8?B?VzFSdkVWSVJLT09mWlV2RlptVTJOZ0hyRC9JYjFDUldGbTk1OVpFNnpHNXlu?= =?utf-8?B?UWE0WlBsUnRQeTZhUWNDL2d4dHlCdkVFektnVW01MGc5bGVUVk1GUVc2U1li?= =?utf-8?B?ck9yaTk2NDloQTY2eDBYUHkxRFY4OEZxM2tPMFkya2sramxDR1hvMms0dmFK?= =?utf-8?B?NW9OQVU1VEVjNG9Jb2NvKzk2aW1Gc1pkTDhwbTAyYVpuUCtDRFlNZ3pWTmVs?= =?utf-8?B?TVRodmsrb2VRdWU2VjFiRVFpT0F3SXNqU0ZmS21UYUtROCttS3BaN3ROcTFI?= =?utf-8?B?VlE0WDBrQ1o4SmRKSlIraXBZOUliZDlON2hYN2VMcmpWMXcwYTlzNlA2Wmdp?= =?utf-8?B?WktTQnVpUUhWREVqeUZoMUpRQ0VkOHU5NUZHVDI5dnJ4Vk5nY1lueGVrb2E3?= =?utf-8?B?WUZJRGpQZDRLa1dmV3MyN0pid1RnRnVIdGlWQVI2QXlMVlFEVERvZENpV2xq?= =?utf-8?B?MWpQT3BCbHFKdGV2YncybFpROVpZZWNTK2t0Z293TjhvRWY1ZDAvSjF4Sk95?= =?utf-8?B?Yzk0Nm1XTnRieFNHeEdaN2RMZ1ltaFUyN0VaR2hYeEVYZUlwLzl3NU1qczBl?= =?utf-8?B?NXpXbEswR1hEVzU4UFlFWHBqTkxyTEhnL0RQRXlVOVRna3NKaURVK29kSW15?= =?utf-8?B?ZzRyanVmYkQ3WGRuR1IrM2ZpUTVmZXBHSkVsSDdyMXFmT0ExRmFhVy96Rk16?= =?utf-8?B?UlRDNG12ZjR0OVRTd0FXTnpDd2ZTbWRaTnl3b0dmeTQ1OVRZT3NPVHR4SXVo?= =?utf-8?B?OGNITVVHZkJDa09UbURjUjB4VHllcWlGdWxKWHo5aU9JcDZ0VUFhZzAxRXdz?= =?utf-8?B?eENDd0IwaFI5dzBRbVdFY3BuN1hMcHlXb3pWM3dXU05ETkdSODIxQnpLL0NY?= =?utf-8?B?VUlMejNyS0dkM1RRRFh3enh3VCtvRlhaZ0s3RnA4K1JHMGx5dHI2Q0NrV1Zz?= =?utf-8?B?YmFVYXVzOFZiMStUeEM3cURVVk81bkNVNWliZ0V3cWtoYjlWRzFEL29CRzZD?= =?utf-8?B?bUprSm84MDVtaU05VVg5dmo0QmVkZmcrQ1FJWTMyc1VIQzZzMlZML3JvWmdL?= =?utf-8?B?aUZ1VmhIWjVUMjd5L2piaDlpRE9MM21QYjdKNmxXY0NZeXFoQWJqc0lGeTV4?= =?utf-8?B?Q1lyeDhnZ3A5ZWgvRnZaRlBBMDZPeEljcUlBSHVtdUtQN1I3bnVnTlpsOWVB?= =?utf-8?B?c1hJMDdRYUNESWZheTYrNEJQQmI5eldOaGpBaEVjSzdCcHZ0UVJiZ1hXTUFD?= =?utf-8?B?eE1jakJkRG1nSGdkTnlhbFVCQVJCQ3RuVmpZbnNycVRlOC9WOFBMbWIxTGpC?= =?utf-8?B?RWc3ckFmUTg2ajR4NCtUcnZlQ2t1blJyYXo1dzdwWjJLOGxYd3hxVHpPYjNH?= =?utf-8?B?TW1tWjN5NVVtVW5uRHdhQnZnMWl0TVJDbVY3SmdjK0dlRDFlME9td3hPR0Iz?= =?utf-8?B?T2luOG12TnZEMnY1NWxydUdOY1NMeEVhM3c4VTlLeldVeXdKVnVXNzFRTTZ3?= =?utf-8?Q?vX5BCPQzqjCa6vIW4KkzVik4G?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR03MB2368; 6:gpgLXUDHc6c5sLPD29RpWYh0N/Sr8GRPCja9z9D6R0+CYhtxX4zIwO4DP/1F7rbodzZC/c5gM4ucXePyAY93clLTt5vK33/Qy/YZqEKpfypSw9X4XMOtd7KR2St9ibQ2681ufwIT+9EwUe89kEsFD0PTQp3R5wL2YKZaFYsQ4Z7pI5wGQ9yNPDIs2rdpc6EueddqQadE36fYvcCUeEgGwzdLoCRZqEKhxYIeQwPYZPXZo/1OWQ72uOSOIg1VITGr62Wt0sczF5tfW1aIX9OA2M8bdnXyGNHkpX6GLDMCwJTv9Xlml8J5DTpWWEUFBsYN06EGjtYWmlpGeN8dKAx7Eg==; 5:vMRWp5EgeXkUfNSSXYY19L/XcRQ1woc0afMEZzBg1dy65+v1Vlxr1o84nHtuUmMcQjoqZK+PqphitvusyDb5WQn4b0EnWhGT5NmFY1jjd8AIDTCDImoysu7k52k60WEzM53xOKAGFCxQ8isp1UAZUg==; 24:2lhQ2Rq7irwz2u5e+uJGgPdEWvkrwr2f16koGwASUWBf9HTaovu9DLiZRM32b6fncBdEXjZGg+vc4zf3+xPwmtvtrkGssX8oD8d3CzF9Qq0=; 7:OdeaM+aXNT/HpwSUrNkYSbfCvDkLLobe1BJtgd6vnaiLpmPSEtmDmO3tGAY6722z4/VLPqd5yZpyw+EN+/v730Dhtbec1cWUVYuJ0oqbhhd3t2NEtCt96r8MTTb9rVG1oesl/JMZkl4UqXCIsRAqVZcSh22uB1oAbb+C9g0SLJEAlw7C4nUS7GcPCGuhSEolg3alOPU9UHEW2dJnRqVo5vXpwXOiGRUnNVFo++7sgmk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Oct 2017 12:17:33.4422 (UTC) X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[192.88.158.2]; Helo=[az84smr01.freescale.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2368 Subject: Re: [dpdk-dev] [PATCH v2 01/12] lib/rte_security: add security library 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, 10 Oct 2017 12:17:36 -0000 Hi Konstantin, On 10/9/2017 7:12 PM, Ananyev, Konstantin wrote: > Hi Akhil, > >> -----Original Message----- >> From: Akhil Goyal [mailto:akhil.goyal@nxp.com] >> Sent: Friday, October 6, 2017 7:11 PM >> To: Ananyev, Konstantin ; dev@dpdk.org >> Cc: Doherty, Declan ; De Lara Guarch, Pablo ; hemant.agrawal@nxp.com; >> Nicolau, Radu ; borisp@mellanox.com; aviadye@mellanox.com; thomas@monjalon.net; >> sandeep.malik@nxp.com; jerin.jacob@caviumnetworks.com; Mcnamara, John ; olivier.matz@6wind.com >> Subject: Re: [PATCH v2 01/12] lib/rte_security: add security library >> >> Hi Konstantin, >> >> Thanks for your comments. >> On 10/5/2017 10:00 PM, Ananyev, Konstantin wrote: >>> Hi lads, >>> >>>> >>>> rte_security library provides APIs for security session >>>> create/free for protocol offload or offloaded crypto >>>> operation to ethernet device. >>>> >>>> Signed-off-by: Akhil Goyal >>>> Signed-off-by: Boris Pismenny >>>> Signed-off-by: Radu Nicolau >>>> Signed-off-by: Declan Doherty >>>> --- >>>> lib/librte_security/Makefile | 53 +++ >>>> lib/librte_security/rte_security.c | 275 +++++++++++++++ >>>> lib/librte_security/rte_security.h | 495 +++++++++++++++++++++++++++ >>>> lib/librte_security/rte_security_driver.h | 182 ++++++++++ >>>> lib/librte_security/rte_security_version.map | 13 + >>>> 5 files changed, 1018 insertions(+) >>>> create mode 100644 lib/librte_security/Makefile >>>> create mode 100644 lib/librte_security/rte_security.c >>>> create mode 100644 lib/librte_security/rte_security.h >>>> create mode 100644 lib/librte_security/rte_security_driver.h >>>> create mode 100644 lib/librte_security/rte_security_version.map >>>> [...] >>>> + >>>> +struct rte_security_ctx { >>>> + uint16_t id; >>>> + enum { >>>> + RTE_SECURITY_INSTANCE_INVALID, >>>> + RTE_SECURITY_INSTANCE_VALID >>>> + } state; >>>> + void *device; >>>> + struct rte_security_ops *ops; >>>> + uint16_t sess_cnt; >>>> +}; >>>> + >>>> +static struct rte_security_ctx *security_instances; >>>> +static uint16_t max_nb_security_instances; >>>> +static uint16_t nb_security_instances; >>> >>> Probably a dumb question - but why do you need a global security_instances [] >>> and why security_instance has to be refrenced by index? >>> As I understand, with proposed model all drivers have to do something like: >>> rte_security_register(ð_dev->data->sec_id, (void *)eth_dev, &ixgbe_security_ops); >>> and then all apps would have to: >>> rte_eth_dev_get_sec_id(portid) >>> to retrieve that security_instance index. >>> Why not just treat struct rte_security_ctx* as opaque pointer and make >>> all related API get/accept it as a paratemer. >>> To retrieve sec_ctx from device just: >>> struct rte_security_ctx* rte_ethdev_get_sec_ctx(portid); >>> struct rte_security_ctx* rte_cryptodev_get_sec_ctx(portid); >>> ? >> We would look into this separately. > > Could you clarify what does it mean? > It will be addressed in v4 or don't plan to address it at all or something else? We were thinking of improving this beyond the scope of this patchset as an incremental patch. > > >>> >>> Another question how currently proposed model with global static array and friends, >>> supposed to work for DPDK MP model? >>> Or MP support is not planned? >> multi process case is planned for future enhancement. This is mentioned >> in the cover note. > > Great, then I suppose you should have a generic idea how that model will work > for DPDK multi-process model? > If so, can you probably share your thoughts, because it is not clear to me. > Let say user has an ethdev device with ipsec capability and wants to use it > from both primary and secondary process. > What would be a procedure? > Can user use the same security instance from both processes? > If yes, then > - how secondary process will get security_instance_id for that device > from primary process? > By calling rte_eth_dev_get_sec_id(), or something else? > - how guarantee that all these func pointers inside ops will be mapped to the > same address inside processes? > If not, then does it mean each process has to call rte_security_register() > for each device? > But right now you have only one sec_id inside rte_eth_dev_data. > > Would secondary process be allowed to register/unregister/update security instances? > if yes, how the will synchronize? > Same question for session ops. > Currently multi process case is not handled and we have not put our thoughts on resolving this as of now. We were planning to improve this beyond the scope of this patchset as an incremental patch. >>> >>>> + >>>> +static int >>>> +rte_security_is_valid_id(uint16_t id) >>>> +{ >>>> + if (id >= nb_security_instances || >>>> + (security_instances[id].state != RTE_SECURITY_INSTANCE_VALID)) >>>> + return 0; >>>> + else >>>> + return 1; >>>> +} >>>> + >>>> +/* Macros to check for valid id */ >>>> +#define RTE_SEC_VALID_ID_OR_ERR_RET(id, retval) do { \ >>>> + if (!rte_security_is_valid_id(id)) { \ >>>> + RTE_PMD_DEBUG_TRACE("Invalid sec_id=%d\n", id); \ >>>> + return retval; \ >>>> + } \ >>>> +} while (0) >>>> + >>>> +#define RTE_SEC_VALID_ID_OR_RET(id) do { \ >>>> + if (!rte_security_is_valid_id(id)) { \ >>>> + RTE_PMD_DEBUG_TRACE("Invalid sec_id=%d\n", id); \ >>>> + return; \ >>>> + } \ >>>> +} while (0) >>>> + >>>> +int >>>> +rte_security_register(uint16_t *id, void *device, >>>> + struct rte_security_ops *ops) >>>> +{ > > Probably const struct rte_security_ops *ops > >>>> + if (max_nb_security_instances == 0) { >>>> + security_instances = rte_malloc( >>>> + "rte_security_instances_ops", >>>> + sizeof(*security_instances) * >>>> + RTE_SECURITY_INSTANCES_BLOCK_ALLOC_SZ, 0); >>>> + >>>> + if (security_instances == NULL) >>>> + return -ENOMEM; >>>> + max_nb_security_instances = >>>> + RTE_SECURITY_INSTANCES_BLOCK_ALLOC_SZ; >>>> + } else if (nb_security_instances >= max_nb_security_instances) { >>> >>> You probably need try to reuse unregistered entries first? >>> Konstantin >>> >> These APIs are experimental at this moment as mentioned in the patchset. >> We will try accommodate your comments in future. > > Again could you clarify what do you mean by 'future' here? > As I said before, these APIs need to be re-looked to incorporate the multi process cases and better memory utilization. We intend to include most of your comments separately beyond the scope of this patchset. I believe the complete code should not be put on hold due to these issues (multi process and optimizations in register/deregister APIs). As per my understanding the code is not impacting any of the existing functionalities. However,we will discuss internally if these can be resolved in v4 or not. >>> >>>> + uint16_t *instances = rte_realloc(security_instances, >>>> + sizeof(struct rte_security_ops *) * >>>> + (max_nb_security_instances + >>>> + RTE_SECURITY_INSTANCES_BLOCK_ALLOC_SZ), 0); >>>> + >>>> + if (instances == NULL) >>>> + return -ENOMEM; >>>> + >>>> + max_nb_security_instances += >>>> + RTE_SECURITY_INSTANCES_BLOCK_ALLOC_SZ; >>>> + } >>>> + >>>> + *id = nb_security_instances++; >>>> + >>>> + security_instances[*id].id = *id; >>>> + security_instances[*id].state = RTE_SECURITY_INSTANCE_VALID; >>>> + security_instances[*id].device = device; >>>> + security_instances[*id].ops = ops; > > BTW, I think you need to copy actual contents of ops. > Otherwise you assuming that ops are static > (would be valid though all processes lifetimes). > > Konstantin > Regards, Akhil