From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0089.outbound.protection.outlook.com [104.47.36.89]) by dpdk.org (Postfix) with ESMTP id 17776F6BE for ; Mon, 13 Feb 2017 15:39:05 +0100 (CET) Received: from BLUPR0301CA0023.namprd03.prod.outlook.com (10.162.113.161) by CY4PR03MB2952.namprd03.prod.outlook.com (10.175.116.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Mon, 13 Feb 2017 14:39:04 +0000 Received: from BL2FFO11OLC015.protection.gbl (2a01:111:f400:7c09::118) by BLUPR0301CA0023.outlook.office365.com (2a01:111:e400:5259::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16 via Frontend Transport; Mon, 13 Feb 2017 14:39:04 +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 BL2FFO11OLC015.mail.protection.outlook.com (10.173.160.81) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.904.16 via Frontend Transport; Mon, 13 Feb 2017 14:39:04 +0000 Received: from [127.0.0.1] ([10.232.134.49]) by tx30smr01.am.freescale.net (8.14.3/8.14.0) with ESMTP id v1DEcvMH021341; Mon, 13 Feb 2017 07:39:01 -0700 To: Declan Doherty , "dev@dpdk.org" , "De Lara Guarch, Pablo" , References: <2d48b97f-bb39-09e9-5ea2-1fc265459a87@intel.com> CC: "hemant.agrawal@nxp.com" , "Trahe, Fiona" From: Akhil Goyal Message-ID: Date: Mon, 13 Feb 2017 20:08:57 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <2d48b97f-bb39-09e9-5ea2-1fc265459a87@intel.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Matching-Connectors: 131314703445314842; (91ab9b29-cfa4-454e-5278-08d120cd25b8); () X-Forefront-Antispam-Report: CIP:192.88.168.50; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(336005)(7916002)(39450400003)(39410400002)(39400400002)(39850400002)(39860400002)(39840400002)(39380400002)(2980300002)(1110001)(1109001)(339900001)(3190300001)(189002)(199003)(24454002)(377454003)(53546003)(6666003)(68736007)(83506001)(50466002)(6246003)(2950100002)(2501003)(105606002)(626004)(106466001)(8936002)(76176999)(2870700001)(50986999)(64126003)(54356999)(92566002)(4001350100001)(33646002)(31686004)(4326007)(7246003)(38730400002)(305945005)(2906002)(5890100001)(36756003)(8676002)(7126002)(81166006)(53936002)(85426001)(97736004)(47776003)(81156014)(120886001)(8656002)(77096006)(54906002)(65956001)(104016004)(356003)(65806001)(23746002)(229853002)(189998001)(5660300001)(86362001)(65826007)(31696002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR03MB2952; H:tx30smr01.am.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC015; 1:Anh5Xcsa6V4qUAk/r47ee99LlW8G2TsnUGJsEGBTixgMJwfPIJ8PG/JERG9aWHAy+Sn+n0PQe9coi3QSPO2RFFmT2Y1E4UbFE4XwwALZPDd7MsMGZ608OH5GJZUoaH5deoSvNiL26h28qxp/gOgVGHBE7Y0il5uxaU4P+HVXWARW4uByQCrz2s/1WOkljdpBEFFXjahZohAPIFW+5pzo6OjWorSuE/CSwnzQuS1PO9SXceVD/Tluo7FTFAF54Ib5uwAVQVXW9ZZ9b6jVlrW72rmnlHC2fQ7IBDBSeJV59vOt/Nj18K+8qzfnq82AFD7juJo2dvuoGttBfUae8D3PpWDOBoVwrHE7HJO9FfkQ+GNQmp1EK4iAJFniTzW0ZSFScrSG65rHcfBeP+V/fDVg1FX1IFzTLfHWAF99CI0JxZcUQtdy/Urql+mVMD98FejmIXk272HqHlfgixwM1EmfsyZ7ftqeyViDSmWuI7ECDQOuVTMhMFOU3nndDxOSl1ljNNY0BgIZF+7eQk8gBBvQGk7U2F8NU0fX5QJtfeknmgYVJfELvAyTiHrkeO05d+KsuL5xkfCgKmJTSktIyCF68DVAb5prYswT74Hkvz7tAXkUvyxGrlyIAmpBWRF7zBu3 X-MS-Office365-Filtering-Correlation-Id: 59cb139e-eb7b-4704-6bbd-08d4541e0f19 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR03MB2952; X-Microsoft-Exchange-Diagnostics: 1; CY4PR03MB2952; 3:dsoVdbspcPRQUelbobmYnFhCpkVUvvlmqxMXv+wUHgsj42+Q1PJp4FHCWOCZGNPwlipORGtWUhxSm0TWO1wW+SyTBY6K3nriuJmbARPoIW3wmt1Wrht96L5YDEWtEaroQN1xx/j0+PxyoFSAMJInutEOgEZsw3Oe3VUuI4/3Wqegmtf35YsQxZkJTctLRIUJEAGXBXoVRbA2hpsE75Q1loCuzT3KUFT7+fhSry3RhIrxqPM6xbdN816k5qUnwI/zaXayM2xSPuTbRTmBsaWWu9hiVq3DQNz0XFm3m9ZaLtaeWaJJbIi/q+HWse97WFKTUPyhBCOFqklBetEf6chItKWR3MJqFwTZNI3XXF49N7PFdql3zr3ecdKG4JFaE8bs; 25:iGKj8zIF89sDr1udi6Kv1GzIVshAJ3vrTsY8mw/zcHjIGwSnrL8um0JFn6nEj24s1w/nGnTIiuAg98N7AwhF5lX65RcEiYbMnJwGQcW7olP5h7jgPGOc3rb3g4CEHgTDHSGX6SFcIdz+ZWgG+iz2lhiSo4zHVwb3NIxIouuxjxN/XcqhoIi/JYKkwBLdUnzWFMHoCqW60TKqrj1dPbDWbr1p4l10Qn1xdGD5eBgHT5/sP/xa80rkfX95V0upuWXRFODMuLAiovbEqaM/HDER3hNJgTmGgt5pmHQAAjSBbvbnCFk4paaz/7pAYDrhSJvf5O03bAw9aGMbT2iasKzMek46KbJUT2J35kRYTKqeWQ0wjHt2+a7ZsPaYa/9W7HRane1ZdF03QaJ3KaxoscYs15aMjunk2KuEOtRgu/Vu9kT00U+6WS0NWlMq9WlXqbp4LhVUdeukAx5w7OdUnUMKSQ== X-Microsoft-Exchange-Diagnostics: 1; CY4PR03MB2952; 31:7m59Bw6SoSDrT13acA5nTCwzRCG+g/9lFI+rUm5nD0oETZ5Bci4mbsbsujhyVVKer8qbdipNhXYF34iYF1jnqQ+NXHu/KHAsmTQHBfuL6bhs0D/xAQKyTaB7eDTHuOTNxm2w6Cv10802NNxVaHfXCidn3EJyTXjTu0YDAV2JEM6teaV9379a/6OELIp2Lcv1sErBDxi4o7EbDR8Jo8CD8EcIBlWT97pgd5f8SXAq8orwwSborLwKghHtNfLADBaBAd5Xorw1lcNLM+M18BjwhBj46UA/vhFtH7+5vZ9eFRA= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6095060)(601004)(2401047)(13018025)(13023025)(13024025)(8121501046)(13017025)(5005006)(13015025)(10201501046)(3002001)(6055026)(6096035)(20161123561025)(20161123559025)(20161123556025)(20161123563025)(20161123565025); SRVR:CY4PR03MB2952; BCL:0; PCL:0; RULEID:(400006); SRVR:CY4PR03MB2952; X-Microsoft-Exchange-Diagnostics: 1; CY4PR03MB2952; 4:m+cTpsX8JFKcREPmF2xfKHv5xG/8xjtklPBXD4mHogmwTq6xvCMUbHkj3ICDFZryUUfQRTaJBSqEWl7/w+x4BP4YU8NBAZbBFVQVJIB7eoteJgWzNM7P1HomS6h88Z9RTiOdELKH6xWwH/XpVQ8cat6epji1e+i3fbJmz/4N/5d8W0QoNgml9NEgisEwfIZJr/dLOKK/UXjXDD4ZUECFuSKFTLkWeHFnhPVObdX3Pd2JfiU3cscRPG/MfTTOPYJ+yhO52k7BokCMyC+/+/J/BQcjP8BfTrTWakfPRWIGBzgBwBgNRCdw8W2Wl9BjU4KWItbEcZnq9LuWLq9NggedJl3dOekpC5r36OfTxUsumvUmYRDKFeIomzPCdKoHjwiqywWxe7tZCNp9I6KbvjEbnTGr2NIo3c7p3mcVpQsctxEEVuIV5tyQRac4LjfL71vMBozaCgwP1d4wQey2dtkOrb0T3RyKnmLLRovMYbZzJzxE1bsH+BEJV48eQEXk9wkMCac7Gw5El119utzFVL3ZTYVFFKZvdf918ROyvks4KqZTh7qqXTJ6t43tQ9jT2pdEvjkdmoYr9gnw3yRTB60ibfs/wQpxx4vS/S0+X8txHnG6Iy0DFxIaRQQQfswxxVNUZntAZKPKyS0mQEgH2zf4T0U0S6Fb88esve7nOZ8GkwaqCwl52HYyW/UX2U71psSADXigOQbMpoZ+OxnNnhODbw== X-Forefront-PRVS: 02176E2458 X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; CY4PR03MB2952; 23:M1UxTAcKXiHilKuZgxoUmGGkpyMs9/8iCaYp0?= =?Windows-1252?Q?u1KxPFaTsACNUIlclusnnPadWSuxREbLR891Ozr7X+o9y93pvzKzzjFe?= =?Windows-1252?Q?bdUHuBnVrolrudLLaWcr96fhf8hD43dT/5toK+2bpigrmRuqkcgX3JOI?= =?Windows-1252?Q?1ljaOVhem5fa+SArUIfRJG1fLsr0oJ450evSnhanI3Qz8Kq4mx/+TrOB?= =?Windows-1252?Q?pRU3OR16PUOF0ysrbLro13Cj101YRvXAtsaYvZRpyZY3mVZnt9b6AtNb?= =?Windows-1252?Q?DBkHta8JV5nY+Q8JDKADVNLztH8FRszcIwN2t1yXQ8LgezRzJuvU62a/?= =?Windows-1252?Q?WkhW14hBfOenzbYxQ76kQ2BgqukkHrNFfDJt893yaUbIgsrtayVJ9XA0?= =?Windows-1252?Q?7O7AE6z3O28YgJAtADbKJjXiqjoZJE1HKJ+9WM+5OcErqQW8guBbTfBJ?= =?Windows-1252?Q?PUs/9UEoE7ENNzqAiuHs/pjyvTDd4badgl8eATtXrMiBkWIr+jwRSyBw?= =?Windows-1252?Q?ylklCeGAool/Jh1KG3THHiv2TKZUk3ucWMRB6zd2oKWR8XQHUSq7swZ2?= =?Windows-1252?Q?44LDuqGaHhoukgSskg+DojG9VZDjO/JoIQSs62lQuJtv47vfhS/n3EkG?= =?Windows-1252?Q?rZnz4JNuXcrVEptyHB68FSawscSA1FeX5A8m2O/5DftqY7pQKm4kX8SY?= =?Windows-1252?Q?Gq50QYdyxukUgvXZjIrD5pQpGwAQxTnFeE1kZ5Ax+uixTj/C0+9Y0UwT?= =?Windows-1252?Q?nK2zJ3YqD7KsuUdVjiDw5FAuuwDEuBAfkDb6eHZ+umy0Q3n6Y0cg0Wrw?= =?Windows-1252?Q?/veAn1VKmg+b1Gc0zgaa9sLMnC5gxpqsg8SgAaW0wwOwAgnPmLXy9E9U?= =?Windows-1252?Q?ozTHJF3HOMxHDVDxf97P6tPP+IV44Fcj0GE8FreFcS4axgGl6Si+/431?= =?Windows-1252?Q?mAZ5oEvcUWZq/seOOv+IOI4f8/8bFcDxahkOSnk1VBztEMjq0ZWhe0gG?= =?Windows-1252?Q?WYQ37dHjhf6ZE+H/11FSr3lQg3+TiuNXf2Wz51lMBc/4QZ/xi+Ie8K9Z?= =?Windows-1252?Q?zZiXNFmoWT3mgvnlXncQyYlsTA3w9Pk1U/TAwz3ce5aahjIh9IR+JMbA?= =?Windows-1252?Q?8IAoaXH/bgmCYEyuxkQ6PPZkVnU1GfyynB5XAMwLslvdrugRO2TBQCai?= =?Windows-1252?Q?sp+FH3fTbDpvuOQDY5EXzYTMPmOBvBrKFdOCewoTxoNPWUBY1G9Bfcvu?= =?Windows-1252?Q?OfU2u1iGK6Q1+FlgGuBqgv0OybF3q/tFQpXU6d2btuBu+8S6whLPFFL0?= =?Windows-1252?Q?z2FAnwzwkJg/UWwttMouLX7JjhBkn6SPyFv0Jqc+h0ZfsGfoWRohS31c?= =?Windows-1252?Q?QtbmR4CslRnFdk6mqEQ4IgXuRkEHaU5aWckjMkIkbP3WZxJjjJ67xnFx?= =?Windows-1252?Q?AYKjOQoGmx33usJoELSP0YdvOZRCNLQCSjktg5lFkLH980NYmLLS4oES?= =?Windows-1252?Q?MQNrLpD7ch9k6XnBpAOR7hUSbYntQCtEQahrV01Xl64zJQGdAnVtP1ll?= =?Windows-1252?Q?IOLofPUs0O9yv5rf0riYmGKTNCpnXXXEYEK2G8DMfw1gcYCU9/y8qckH?= =?Windows-1252?Q?dPWNSNDpauzqnUFmgFABzR2BJaNe1rh8RMNmYk0Bz+5HeIEKdMXsKyhu?= =?Windows-1252?Q?N5wgmcOmb6HkwihiJPCfBaQ4c77Lji+oTFxgWHug8htdVj1oMEJzPWB7?= =?Windows-1252?Q?hXS3ckQ5huBedt3Rvs/X9ODWhnaK3i7HMukzBMrbPlVNwBDQf0g8JGuC?= =?Windows-1252?Q?tjZ?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR03MB2952; 6:rVSIMcfDxY17xjEFnQolpNNQxWzJBZ2oJ00GiAJDm+eKlY37zT2sG+UcNzF37bpc2IeoYujuETMHRetwB7XJd4/NlGkMNF3WscvDGiGmTiPOWzdFJ1J3ENQJBXQp22bRYgbyozjun7El3ucNBWrbHTdFVGeQpcT7fmq7uGsiHP/eFYbX491ez8kqvwGqjDe0heGv/CdoANt5X2NEeLxCfzK1+N9E3uLiQ9vc9N+Lr279rEVji3Ldlh9yvIPr+M77YuQdiVSlxaXzCEBhs6+y9m5G1tQzh8/aG9xB2FnSBYmswD5BNL21SBYuH0+MHpZtnLXkAEnTcy+Z63Jsbl7ZqEP2r4D9Y3T3AOdCkiXey9fKyygE4RdPWg6W24Xrq/tonVu102xJdKsNfgd15FhqQjwxnpxGbVBZrImBiWzYnKs=; 5:e5nABN5UNt6KRqGIsEWfujCej4v1CSA3LINL+Ky7ko57gQbBiABRLP7CveNkSIddr1X6SVV+NdfazrhBwY1bwCyxNZtyzEV1YJbYv7M7SwAvu+VsySuCFeiH9u7JFOy2KKBwhCs9t5IAGSqpgSB7DZzDgjl7HetiEC60xI0vFgHkTPTeY1fhecKRAui495VZ; 24:4ufpMCDbn1VEP4wA8R0kG9vRCCh7kEFI2MsBSSJxBGXqCvO9dEXT03FpH5jWg3Ngt0fGApsq6wWg6jFlMNlEaaPyv7+KOGcBGFJQ4ykJCa0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY4PR03MB2952; 7:RlASUmeMb42yDvq9CXnXcI6/fW/VYH8A25JORkq8v2K9SJWYDJO4rA6HMWCU9hsDs3fH2uD2omDlGZw85HdumVL1l6C0GfkObGwbR5gGD3dzboGGUL6Fm9I2DRmfWpiYE3D3c29s71tWgTh4uJ+9Sy/bTnMitmuGoRMVwaUd0/N7ZGanUxnTlGc6cHFEH6fj2Ity7iQfcA0MEn0viMFfFGGLU6GxfYXg6XshRzcgfcoZuXxoSOj91rqSPtfF10ki42gmCOuZNFq+qe/iaJU0x/rDNVZn8URUFA7LmUIA6tlx3wE05AgSSsMpRrIoIs65c2LOjyWSg9DTFsHcJ6Xzr8iyAWrY1EAUrGjUST5wXwNq19uiGLBpp0NDM1lPHlJkdfFuCTLXMjWthye0jSpZXuf7rSdf/Ip20wN6ryOp+4WD2KErgPJI2Nb23equXDQeigmEDb8wutpJ9vKVbLBJoVHjmrT2LpghPBNZEkS/93URYZghUHzfMZSet8apNykG9tsgYaU3dq21K6k7dItvYQ== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Feb 2017 14:39:04.3130 (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.168.50]; Helo=[tx30smr01.am.freescale.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB2952 Subject: Re: [dpdk-dev] cryptodev - Session and queue pair relationship 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, 13 Feb 2017 14:39:06 -0000 On 2/8/2017 2:22 AM, Declan Doherty wrote: > On 06/02/17 13:35, Akhil Goyal wrote: >> Hi, >> > Hey Akhil, see my thoughts inline > >> I have some issues w.r.t the mapping sessions and queue pairs. >> >> As per my understanding: >> - Number of sessions may be large – they are independent of number of >> queue pairs > > Yes, cryptodev assumes no implicit connection between sessions and > queue pairs, the current PMDs just use the crypto session to store the > immutable data (keys etc) for a particular crypto transform or chain of > transforms in a format specific to that PMD with no statefull information. > >> - Queue pairs are L-core specific > > Not exactly, queue pairs like ethdev queues are not thread safe, so we > assume that only a single l-core will be using a queue pair at any time > unless the application layer has introduce a locking mechanism to > provide thread safety. > >> - Depending on the implementation, one queue pair can be mapped to many >> sessions. Or, Only one queue pair for every session- especially in the >> systems having large number of queues (hw). > > Currently none of the software crypto PMDs or Intel QuickAssist hardware > accelerated PMD make any assumptions regarding coupling/mapping of > sessions to queue pairs, so today a users could freely change the queue > pair which a session is processed on, or even go as far using the ame > session for processing on different queue simultaneously as the sessions > are stateless, obviously this could introduce issues for statefull > higher level protocol using the cryptodev PMD service but the cryptodev > API doesn't prohibit this usage model. > > >> - Sessions can be created on the fly – typical rekeying use-cases. >> Generally done by the control threads. >> > > Sure, there is no restriction on session creation other than an element > being free in the mempool which the session is being created on. > >> There seems to be no straight way for the underlying driver >> implementation to know, what all sessions are mapped to a particular >> queue pair. The session and queue pair information is first time exposed >> in the enqueue command. >> >> One of the NXP Crypto Hardware drivers uses per session data structures >> (descriptors) which need to be configured for hardware queues. Though >> this information can be extracted from the first enqueue command for a >> particular session, it will add checks in the data path. Also, it will >> bring down the connection setup rate. > > We haven't had to support this model of coupling sessions to queue pairs > in any PMDs before. If I understand correctly, in the hardware model you > need to support a queue pair can only be configured to support the > processing of a single session at any one time and it only supports that > session until it is reconfigured, is this correct? So if a session needs > to be re-keyed the queue pair would need to be reconfigured? yes it is correct. > >> >> In the API rte_cryptodev_sym_session_create(), we create session on a >> particular device, but there is no information of queue pair being >> shared. >> >> 1. We want to propose to change the session create/config API to also >> take queue pair id as argument. >> struct rte_cryptodev_sym_session * >> rte_cryptodev_sym_session_create(uint8_t dev_id, >> struct rte_crypto_sym_xform *xform) to >> also take “uint16_t qp;” >> >> This will also return “in-use” error, if the underlying hardware only >> support 1 session/descriptor per qp. > > I my mind the idea of coupling the session_create function to the queue > pair of a device doesn't feel right as it would certainly put > unnecessary constraint on all existing PMDs queue pairs. > > One possible approach would be to extend the the queue_pair_setup > function to take an opaque parameter which would allow you to pass a > session through and would be an approach more in keeping with the > cryptodev current model, but you would then still need to verify that > the operations being enqueued have the same session as the configured > device, assuming that the packet are being enqueued from the host. > > If you need to re-key or change the session you could re-initialize the > queue pair while the device is still active, but stopping the queue pair. > > Following a sequence something like: > stop_qp() > setup_qp() > start_qp() > > > Another option Fiona suggested would be to add 2 new APIs > > rte_cryptodev_queue_pair_attach_sym_session/queue_pair_detach_sym_session this > would allow dynamic attaching of one or more sessions to device if it > supported this sort of static mapping of sessions to queue pairs. > > >> >> 2. Currently the application configures the *nb_descriptors* in the >> *rte_cryptodev_queue_pair_setup*. Should we add the queue pair >> capability API? >> > > Regarding capabilities, I think this should be just propagated through > the device capabilities, something like a max number of session mapped > per queue pair, which would be zero for all/most current devices, and > could be 1 or greater for your device. This is assuming that all queue > pairs can all support the same crypto transforms capabilities and that > different queue pairs have different capabilities which could get very > messy to discover. > >> >> Please share your feedback, I will submit the patch accordingly. >> >> Regards, >> Akhil >> >> >> > > Thanks for your feedback Declan, The suggestion from Fiona looks good. Should I send the patch for this or is it already in discussion in some different thread? Also, if this new API is added, there would be corresponding change in the ipsec-secgw application as well. This API should be optional and underlying implementation may or may not implement this API. Regards, Akhil