From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0063.outbound.protection.outlook.com [104.47.42.63]) by dpdk.org (Postfix) with ESMTP id 0F7512BD5 for ; Sun, 16 Sep 2018 13:07:24 +0200 (CEST) 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:X-MS-Exchange-SenderADCheck; bh=/0xUw8l5i0UziTeHX+NHDMXxFlQuOJiVja8oLdqHQ/Q=; b=RxRlNTU2gJblGNcNSdlDOvFcDduXpH8Cxzz6/t9jei//TvUR9//0EA4jlEn2chfvhn19K/wff6Sy4myXCI/aCuSg+04APpjKEinyEO0OkSz5i6dIxJ23gjuTNgkQNsnktDf3VmTlLtQXA/JENv9ebBsNwu+FeFs68n4G8l5ocfo= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; Received: from jerin (116.68.105.82) by SN6PR07MB5007.namprd07.prod.outlook.com (2603:10b6:805:ac::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1122.21; Sun, 16 Sep 2018 10:56:56 +0000 Date: Sun, 16 Sep 2018 16:26:41 +0530 From: Jerin Jacob To: "Joseph, Anoob" Cc: "Ananyev, Konstantin" , "dev@dpdk.org" , "Awal, Mohammad Abdul" , "Doherty, Declan" , Narayana Prasad Message-ID: <20180916105640.GA4803@jerin> References: <1535129598-27301-1-git-send-email-konstantin.ananyev@intel.com> <358d1b6c-26f2-b125-07a4-cfb1c0e2a57b@caviumnetworks.com> <2601191342CEEE43887BDE71AB977258EA95089D@irsmsx105.ger.corp.intel.com> <475cf471-b46a-671a-5485-0042c652430c@caviumnetworks.com> <2601191342CEEE43887BDE71AB977258EA954BAD@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB977258EA954E9D@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Originating-IP: [116.68.105.82] X-ClientProxiedBy: MA1PR0101CA0031.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:22::17) To SN6PR07MB5007.namprd07.prod.outlook.com (2603:10b6:805:ac::33) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 130ac08d-1146-475d-6a42-08d61bc32090 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:SN6PR07MB5007; X-Microsoft-Exchange-Diagnostics: 1; SN6PR07MB5007; 3:pk9VuWd6NJNbCzT8CqEp3K747aapjkjv5gFdX0A2y+cHdzRRZTu7bDdxeWrzvEJl0IdUybACgXWu1sp0m5H1SylMSxHYU+pFvxfsQwCHKV1EzlEAjcJCKVLCqyiVs2A86/A+w3d5HZx2kjT7JLuKgVi21EbkZW/nTdyztxjbxvEx5MaD6Z77hI8jYOJs26eZHi67SvDhWpwb5iOdEyVS3cygmmWPU6zOLJEvVTzFTIj21lvkrn9+n53+dgVSbxcL; 25:OuLysIHZqtpB8vxFBetKL5eAbrniCnKFr+DQTJwoDymr2IovCTQRmg4NGxbmciEQAawLALmtHPASiAEAsdGhXuEJEo/sjuaO7QOfEcfr7n7s/Vf9lHeaNMx/DvimjOAj8nOeb/DKW7vgCdOs57ctPY/Ch6qIQ6bRrpIxi/fgSE2f2LXivOxWu5GnOj7e1rKu4SupTUyBeE1lpk7VUv6UQLLwSBZj3FVVFGbEnzO9r1qpgEUdaplgQzQy8aq/YCGYU62NhfjrudhVXOXSmTRKzMM8GPtAD+beRtOdOx7X3B1Ul+i5AEPFdDLkmxE1FvO5xYFlNyvui5us67MW2MNvDg==; 31:w90wQRMX6GEhbTDFwblIrLakHRlHbN/aG+/7e3G4epNBVFWQ4W+Z8f15dIdsZlClbJ7+6MEbbFZ8yckKkTXywz2RJR1BnD5X6gH/E3qgxGRxcwozJBH2X85uubiaDEqyrctgBhjCQb1goM1Tn+KJyCN7vDPyMtWZUvefGlQs4pLBrP+2qbVrW5/VU6jj5gOYLY0ZzawmYX3i4IrHqQrMtFXcZLJJg48p2FVVZvCiTig= X-MS-TrafficTypeDiagnostic: SN6PR07MB5007: X-Microsoft-Exchange-Diagnostics: 1; SN6PR07MB5007; 20:G1tYhMlLhvTh8bSRycrvdg5Lccu8ywcRko/ylcGmL2ap/huiPVN/72C527B+vrBk2nobrtvtEk3e37xLNfpDgHTehmsbtlpQDxVls/9cu8xFkJtzwjGd1h4C2Qh1mj+dktOYSM4EAnNis/7nihPVLf5ofhp/XkocOCvptTz8mXWp0DQ2WHQNqqlYOhR/BZsuecHQdvTIR0qT0iFfs+nZVWjmdWZTax0cENh+nTrGlQCrJwqQCVfSG2OY2SYNoSaphGT1UgjTnYM/GA8r+/D3FPyjhaXIQm9z3zTR/lWtabAcrg1htkxn9rwqTB3diwBgwaaJA9x5CRZTeq9k8cUpjlE3uH5gh/a5/dlK2eez4+DGCrDxKN+h7fJ+bNbzadcnnW//Acncov9l7ae0IzcLAFem8WSE9o98ROnD9ecOs23AzgRW9QRYhCbKjvDiHN24oVgTBLnblz6+auHKFYfZJnhuMU5t/gIhq3brGvU5RkyuShDN3sZXodidowBLwu21c/+zJZDxqRJs9Yzo/XkmVG/kz6scvcHTZ1ybiTpP42B//zlUfz5oOcU7y/WByEfP8Vkio1VlzZBicUznFDPwlLcbx29j8FV/5U+VAsxclDA= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(211936372134217)(163750095850)(228905959029699)(119230021023882); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(3231355)(944501410)(52105095)(149027)(150027)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(201708071742011)(7699050); SRVR:SN6PR07MB5007; BCL:0; PCL:0; RULEID:; SRVR:SN6PR07MB5007; X-Microsoft-Exchange-Diagnostics: 1; SN6PR07MB5007; 4:4tJszuBjlvoQlAM4skYK3FUYPAOa5DX7Oua29GFlO2PGxeG34fSlQESDaLlpOYwXyTbkVT9/O74XDmipyxE5l8H7umIEhjCSnB58iDT9aw+qVBSxm4oZqwcV+Fzo4QoA2y//u0LBJPMh1RSEKIwggdOjvCBx9SujCrbFIokgxGYAYKfK+iXUtKAGoL/ubR7ZLwzTUsnzI8b0gMEPr+C1+kjy1TeNWaxRzRg5RY6n2wlgn9ehVN/3tSzncNsAFqBS6yTlaeJnsdnnOBTOeeGiQOcrIdz8AZse8KSU+lOhK54VUitywcZJtl4oJN/ZrfU4dKDPVww9M8jdss/LcAqI8t2162cb+dB6R9z8zv0XlnQV8l8DWnsW16YgsJAlkEeedB63jL3KoMsVgAwzauNRzLOSuvbE9c9rJtV708XIh/1jc8ZZOxjEIQuW+z1IqsVz X-Forefront-PRVS: 079756C6B9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(366004)(39860400002)(136003)(13464003)(189003)(199004)(52314003)(5660300001)(107886003)(486006)(6666003)(42882007)(26005)(68736007)(956004)(6636002)(16526019)(33716001)(7736002)(305945005)(8676002)(44832011)(229853002)(446003)(2906002)(53936002)(14444005)(97736004)(55016002)(47776003)(9686003)(476003)(66066001)(386003)(6246003)(11346002)(50466002)(1076002)(6306002)(106356001)(966005)(6496006)(81156014)(478600001)(81166006)(52116002)(8936002)(410100003)(6862004)(33656002)(105586002)(93886005)(72206003)(33896004)(316002)(58126008)(54906003)(76176011)(25786009)(23726003)(3846002)(16586007)(6116002)(4326008)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR07MB5007; H:jerin; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN6PR07MB5007; 23:Edct2YZlhFkKBUYTmULN0u5PaF/4nzbqKnUmWS8zC?= =?us-ascii?Q?73lCUGEw3CUybIC8YjePq4xm9bcFW64DYkZZIvp82FEl+VKx+Jfilg5EHgzZ?= =?us-ascii?Q?KPrcJR5mibdj/UVDrn+p4wIgn/ZkxIBgF2Aj0r/CFoImRKKjmbDUAkilloph?= =?us-ascii?Q?MERtW4Oa2V636yHc5MPZMZgRdnhk1qBq0AG05Pc0L6yvN32DyqV23X4/59f6?= =?us-ascii?Q?LpbiGZVH2PvZ6A45FvJHsZhnOfp9xphjyjPZ8fRuxXbxbq1SVPT59VmqTRD1?= =?us-ascii?Q?ZSBF1taZIwMEnlX/D+89TQaCnRJzuEKnUF3UVSfhOP+zHqV4F9j5SFhIna7r?= =?us-ascii?Q?jjLph8nw3J6Bw9lDyBnRWfdxB+pDn4q1IkbkUyZMiR9pcZumlyZFTNyv5DXM?= =?us-ascii?Q?6rVAJ3CNu5ZEWjXZdKnxuVpbK1vwnsvnFwGcGk4EZfeR0K6NeJaWn5GJLmbk?= =?us-ascii?Q?z3m3gilt6hKKpGd0YkXih1jmRrTMInRSCWV0UgaqYahSxSRWXZroqkEp5xym?= =?us-ascii?Q?PNsyy11DcDKFhacnEMIZp+0Zy3eJ/GUknM/gjWpWwFELHgIT4SBLDiLFUYg1?= =?us-ascii?Q?Ke/Bu0AegOORlsd2o9SG5K9+DxyDtJiaIvLLFvUQ5MCnCkIMX2WbpZryNtMf?= =?us-ascii?Q?n8oq46aRtIFVuA9XkK6fbXzoX7Hg0XJAAPUlz9C663KrJ4qQPSNdhBj7oNnT?= =?us-ascii?Q?cbim+Zo2njQRVsuDsNo2bbfe8CO7wadONCadA+lB8SwKTZqb4gGbmXrwtPWm?= =?us-ascii?Q?k9P1Py7/drAvz8zosL2qQNiFXQT4wTjoUocpXl54yjjTJyxghZbKEyxdxYIn?= =?us-ascii?Q?B/dhVcE0UFgIpaXc1HRennT9JbIdf44YPuGWxa0LVpPiiYojB5lljwguG/AT?= =?us-ascii?Q?+YloITlii2QGsjbtLfxiILyFUToRrcDemwnyNla+7bPDXn8qdDUbb2v7zyBE?= =?us-ascii?Q?IqHvZrNK8rgAXUwmRJAs3aTlgtToxJgEpdpfxChSBKuluJriDhEcoSkZnJ0Q?= =?us-ascii?Q?FOl8DPUq+LpVfuG2ptOEe9jMiXIIZ3VFz5+6okAkWvVscfaETop8CLWsshU8?= =?us-ascii?Q?4msv7Gh1KxfAaPTk1nVSfJBVv4IB0JJbxPrI/L1RojrPYq/6biqqmSPcPEx7?= =?us-ascii?Q?AfOSxnOvYkPGNoO7R3TNNHubfZbJRYnrWiEu7LHM5NPCnQTCB9jDcope6X8+?= =?us-ascii?Q?Aj7FBjiftBAkqvXDHPXKxMPxGTha5jK//6asoXFEf09Q8HLetK39emlWjbgd?= =?us-ascii?Q?en1SuWKDRo6ZhxrKaMUKnGum/8DZ6E6eUZWnt0FatODKBPbN16MDkNr08MHc?= =?us-ascii?Q?hSaTpu2EFQtLgU+S8hzuyAKlABUPBKDu5YxndihfXkqwEpkaP55Fk+VZ9vog?= =?us-ascii?Q?hPz2TFONSDEGP8Hu71uGfRs+uWhMpRA0NaL3go1pmnZXKBGkuKx5ndGyEfiV?= =?us-ascii?Q?TrcbBpo7z/vvfCojrLMVu85hogQ6qHzpen6XaQmOuafTGVGM9xHkpL3vqw8f?= =?us-ascii?Q?qYrRQuAPVztUQ=3D=3D?= X-Microsoft-Antispam-Message-Info: jZYL5oByNFEYBmMXCykUBBH8o25S88ySSkoeH9lxzbqmGk5/R09M6ZjR7CunZj6R+fdbCLxSbtlSkTl30IpoGg/b6yz5+qeU56CvSY7pOIUwMB2M40un08OvyfHujp5+NYT/6f6xTI0yS43jbJ55UV5hw8x92G5Hf0fCUEHOnEJxrKNGciOWTjPBU8ccQ/MqUUh4uwuTk2Ca5BHvi3pcJl4yU6B9Wb3TJSo8MlGFyndR/fkc9jSDzPP4129XdH+Pd9BU7qhJoJfGaaGIPv+oXphNJGZGbQBzLaNC2T55y0L/6TdqqbTQj4FwQh5j/Fc6o2SjHxf2nKV5z+DmOrF4bzxK0ZmdQsu40oqvzi2pkT4= X-Microsoft-Exchange-Diagnostics: 1; SN6PR07MB5007; 6:z0+IlF3YGdvUIxde5ptTYOd3537ffgXSoBKsseMDT0Fnc79XGVJ1Jr+KVEVx7i6J91J9aU2eDEgy8YQ9yuiZtml8GPGnZ9g4iO8cq2TO/Ed+TV0+SmPg+PTKpFVsuJXyKuYpjhHYByqY34zJonCwKFqwY4C28KUQYjIZj1ozzmnubqZWC6XMfsAmOE+0mj8WSjjUmA1oOd3chJ2BmOoIVhdk3BEMyJ4izm8ksk2x5fPcFZysdRA27m7ILtBR6PlsC89j3BcDaNkHkh+TfWFhJY0PQCuH3V2/40BBb2jb2KuWJWLnROnksvZeDCMDmIxOL5WIFilIGOhJLKcplHgnrHCaXaYGvIjxHp/KuWxTvAbqRYqWatXuXOsSoAw1SGmvO/6FE3sDsPndnCQISzGrQYdQ+gxlALDiVFfwMu4/SenAsE583GvBqBideqDhMIyxQXlRZeWAK835fJfxOELJ7g==; 5:xg1D+x38T4d07en16Wokb/GoONSZx5Oo1/zZc09rTD4htDj47xMbX5zgXSGAFfGrjxD4Vjeu/mtXj+pkBU1VIO/IK9wiGB3BZLSYWzZ2Tzp2c4dUAb6QUrV+oYacVdmrPK/bZxjWkwxNLxb6OZIUG7JW+j3Gfj9pXXIz9i9Vp6A=; 7:sG811d6cQ792hVkCma1ho7GZyXkGV0B4gumM/9yU/xaE7fEc7+zKDvlLNoSRKrmog/LucRDxuLUcjHEEORROKjJH1vWCdwG/oPoYjINuJaDddCkYpRMpTZ0S4poPHGF0bkKom1mr8H9ldjMYjQUM6ED4QZMzOBrmvHsIJn0aZ+94fYqeRKRAg7TePQHsofacLaH4B72RS0Gp0D7KM7bSByaS6UsI4Y6ByivwqJkcVEWu31+WwG41tWcYEDmv9nEh SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2018 10:56:56.5268 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 130ac08d-1146-475d-6a42-08d61bc32090 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR07MB5007 Subject: Re: [dpdk-dev] [RFC] ipsec: new library for IPsec data-path processing 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: Sun, 16 Sep 2018 11:07:24 -0000 -----Original Message----- > Date: Sat, 15 Sep 2018 22:36:18 +0530 > From: "Joseph, Anoob" > To: "Ananyev, Konstantin" , "dev@dpdk.org" > > Cc: "Awal, Mohammad Abdul" , "Doherty, > Declan" , "Jerin Jacob > (jerin.jacob@caviumnetworks.com)" , > Narayana Prasad > Subject: Re: [dpdk-dev] [RFC] ipsec: new library for IPsec data-path > processing > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 > Thunderbird/52.9.1 > > > > > Anyway, let's pretend we found some smart way to distribute inbound packets for the same SA to multiple HW queues/CPU cores. > > To make ipsec processing for such case to work correctly just atomicity on check/update segn/replay_window is not enough. > > I think it would require some extra synchronization: > > make sure that we do final packet processing (seq check/update) at the same order as we received the packets > > (packets entered ipsec processing). > > I don't really like to introduce such heavy mechanisms on SA level, after all it supposed to be light and simple. > > Though we plan CTX level API to support such scenario. > > What I think would be useful addition for SA level API - have an ability to do one update seqn/replay_window and multiple checks concurrently. > > > > > In case of ingress also, the same problem exists. We will not be able to use RSS and spread the traffic to multiple cores. Considering > > > IPsec being CPU intensive, this would limit the net output of the chip. > > That's true - but from other side implementation can offload heavy part > > (encrypt/decrypt, auth) to special HW (cryptodev). > > In that case single core might be enough for SA and extra synchronization would just slowdown things. > > That's why I think it should be configurable what behavior (ST or MT) to use. > I do agree that these are the issues that we need to address to make the > library MT safe. Whether the extra synchronization would slow down things is > a very subjective question and will heavily depend on the platform. The > library should have enough provisions to be able to support MT without > causing overheads to ST. Right now, the library assumes ST. I agree with Anoob here. I have two concerns with librte_ipsec as a separate library 1) There is an overlap with rte_security and new proposed library. For IPsec, If an application needs to use rte_security for HW implementation and and application needs to use librte_ipsec for SW implementation then it is bad and a lot duplication of work on he slow path too. The rte_security spec can support both inline and look-aside IPSec protocol support. 2) This library is tuned for fat CPU core in mind like single SA on core etc. Which is fine for x86 servers and arm64 server category of machines but it does not work very well with NPU class of SoC or FPGA. As there are the different ways to implement the IPSec, For instance, use of eventdev can help in situation for handling millions of SA and equence number of update and anti reply check can be done by leveraging some of the HW specific features like ORDERED, ATOMIC schedule type(mapped as eventdev feature)in HW with PIPELINE model. # Issues with having one SA one core, - In the outbound side, there could be multiple flows using the same SA. Multiple flows could be processed parallel on different lcores, but tying one SA to one core would mean we won't be able to do that. - In the inbound side, we will have a fat flow hitting one core. If IPsec library assumes single core, we will not be able to to spread fat flow to multiple cores. And one SA-one core would mean all ports on which we would expect IPsec traffic has to be handled by that core. I have made a simple presentation. This presentation details ONE WAY to implement the IPSec with HW support on NPU. https://docs.google.com/presentation/d/1e3IDf9R7ZQB8FN16Nvu7KINuLSWMdyKEw8_0H05rjj4/edit?usp=sharing I am not saying this should be the ONLY way to do as it does not work very well with non NPU/FPGA class of SoC. So how about making the proposed IPSec library as plugin/driver to rte_security. This would give flexibly for each vendor/platform choose to different IPse implementation based on HW support WITHOUT CHANGING THE APPLICATION INTERFACE. IMO, rte_security IPsec look aside support can be simply added by creating the virtual crypto device(i.e move the proposed code to the virtual crypto device) likewise inline support can be added by the virtual ethdev device. This would avoid the need for updating ipsec-gw application as well i.e unified interface to application. If you don't like the above idea, any scheme of plugin based implementation would be fine so that vendor or platform can choose its own implementation. It can be based on partial HW implement too. i.e SA look can be used in SW, remaining stuff in HW (for example IPsec inline case) # For protocols like UDP, it makes sense to create librte_udp as there no much HW specific offload other than ethdev provides. # PDCP could be another library to offload to HW, So talking rte_security path makes more sense in that case too. Jerin