From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0088.outbound.protection.outlook.com [104.47.41.88]) by dpdk.org (Postfix) with ESMTP id 138395F13 for ; Mon, 3 Sep 2018 14:41:02 +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=Asb+BFJfr1TtVqAv+wZ1Xu8mjTzhXoqKccDJp3BDSyw=; b=eHZ+1QmQLt9VgTy27xCOQATVQAmqQcxoB4MdmxSI4jUhuQzQlD9z2EMJkzETCe/lgds24p0PCKHUBsvb4PcUxF2XNtzWsex1dnXqkKHPGJLsy6+A+Gx6jHsADPvIdPR0oyhnNZ1lXIC0qS6hu+UZg5PLZTPnCpZTXx7ra9O5qrs= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Anoob.Joseph@cavium.com; Received: from [10.88.100.222] (115.113.156.2) by SN6PR07MB4912.namprd07.prod.outlook.com (2603:10b6:805:3c::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1080.17; Mon, 3 Sep 2018 12:40:57 +0000 To: Konstantin Ananyev , dev@dpdk.org Cc: Mohammad Abdul Awal , Declan Doherty , Jerin Jacob , Narayana Prasad References: <1535129598-27301-1-git-send-email-konstantin.ananyev@intel.com> From: "Joseph, Anoob" Message-ID: <358d1b6c-26f2-b125-07a4-cfb1c0e2a57b@caviumnetworks.com> Date: Mon, 3 Sep 2018 18:11:41 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1535129598-27301-1-git-send-email-konstantin.ananyev@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [115.113.156.2] X-ClientProxiedBy: MA1PR0101CA0006.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:21::16) To SN6PR07MB4912.namprd07.prod.outlook.com (2603:10b6:805:3c::31) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4b96be15-4cfc-4144-9517-08d6119a8089 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:SN6PR07MB4912; X-Microsoft-Exchange-Diagnostics: 1; SN6PR07MB4912; 3:NxJGDQb34r8tzMK97V+1lYdhJchZU+26NjNbl/eQybdumxrPT2WW5xVvZtgFibhiV1PA5q/ljXhPqSbLHoGobni8n1TsJK5fVyd8mKhCC5p5aHWF557LznLjsblBagwnseaj3yE/HKyP6juxvhXQG8JLXNtva5fOvZ8ISqpuk4SXOLo4EldnRlhEdzrpCeQQ+IJkCdwom3dCo4S4WcJTuGi5ZnV1ma7yFmcnr7Aps52rs0ZzmKBDw2eh0DAyA6mH; 25:E4d9FK7vgMX+rUkiT+hnPgLpKPzjut9idvhhllwDiiCcbhC17/WpucqLf9O6WbdnFb7pVB/RC02AML2Jugx5wmcfQo+13mc+bTy6x+sH6c9GcFlKGaJ4VJc021WrIbWY+o9tGEGReVbXkXfgTiogk/k1YAuUAhRfPsHDSjZHwI5kU4dQTasZ3/SJHnxPLKi3gP8qohpk67wGaljNQHL3zJgO3IIAMfrlXZdyJs26oGuBYk5i40Y/EbGbaE0GZEAdSIwPMc8qQlVkZHz7nIr5bNIVd/aVOAb9eS26yYqgbbUI0f4A7MndGz/wNrXAKr1L6ReGZBL4lAti5AXZowl/kg==; 31:6omZgLuvwF6gtGKP0IYEI2MhJaFQOxhr35kOfKOUwU8Z0NnoQgE6WW/DPtiwaHA/ykkGsx6OaCNNQwzVPT+uZctZ9L0A7+XR9MfORvAfZK6QQKYasApLaeq+uipYHyex+X7wwQgOcA7STiWz+EwLJC3zGSxSBktqh9KvQrBrJGHarXksneUcZeC3pxh4P10cRi1d/iUEYFGF2Bo79F+a3BlzZA6CKzzxExs4D0pCmj0= X-MS-TrafficTypeDiagnostic: SN6PR07MB4912: X-Microsoft-Exchange-Diagnostics: 1; SN6PR07MB4912; 20:izDDddIIpZ2ZTdplVzfYUOpdUAC61VDcP4Mo+C1jJgqciUCRpXE/VoVZI7q8/aEfRHEv/BkwTWSKYXMZQwlOdQlcrF8NVQQ1moTnBRmZ5Q8xUzcW6Y9rzGVIJcmr4SmKLRjVaB6B38KE/EW9sUrqOxhwXa+5FgxCxXNQ2bGYMNo7AnASJ/22cnreC6nC1yY3KXJcfj2NRsUCb4K2CAMQYiuoUx96rDw6Y1V0gGe41685pg5A8ofbiTRRFboLorIOJGCRi8eONxlRLbXPR71NLG9ufSp3tT4TBIPABVKHEuALAqeMjsAwt7QqY3/nfWu6QUdjUmKvJeRuL7ieF6xj94JISOY8yL9syLpVq6uGhL9ZIbkibTBgair/6hzDgUjLPlK+Z0bhS3E5av0I8QQa01hnwbXaBs39K+PnF8QO+nx4OkMkOwSJCRQUtXRkvCGEbgCpjXBrnzfuXVdaN+vODMJIYODG3syRd+i/VAcQ6haeOCcE2myKn1xzFxZXBqMRk4h7i/ug7yRFmXX/IZyiqA1IauhFZSrnjWSOM72NU0Dyh3GZ7fTCWRjF/rXdkQt+KNZW0aKVFnqjBBlByy0lmRGqR6CjroZ9iIrQU9Wmd58= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(228905959029699); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(3002001)(10201501046)(93006095)(149027)(150027)(6041310)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699016); SRVR:SN6PR07MB4912; BCL:0; PCL:0; RULEID:; SRVR:SN6PR07MB4912; X-Microsoft-Exchange-Diagnostics: 1; SN6PR07MB4912; 4:Pdure408d3V1+R+suavVxcOwz3F9gs/emZgu1Jl8oc2G+GZde/en1WmWd8v8MIOLPgZemivhFqEIRbHxyEyhlDsyXFgV55vYJ1HEde02wNNFvvn95JEgBYjWiLUF/o1p9T079Tpfyvr1u3xwhvwGAXaHC9V96Da3HP/pLQR8KwRRyVqUAPuizJyPnTn38XCxU8RiI9024qh3xS9Y7WXSM6/2VGzvvd0RMdD0p1j0tL9K2VNnUG1GGAwIcFugRNXRxBSo6UrmcBs/6xmHCnxYQyg6217j9UjbLirdGalTHXGuq2IyQ8v4yqf8NnszkmkJkLopiYxO4lKcri52QcSH6w4Ol6jItRQSxDMOPUiV/iQ= X-Forefront-PRVS: 0784C803FD X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(366004)(396003)(39860400002)(136003)(346002)(376002)(15404003)(199004)(189003)(52164004)(305945005)(53936002)(3260700006)(7736002)(52116002)(25786009)(2486003)(107886003)(52146003)(23676004)(58126008)(6666003)(54906003)(42882007)(72206003)(31696002)(76176011)(6246003)(77096007)(67846002)(81156014)(81166006)(8676002)(16526019)(26005)(4326008)(229853002)(97736004)(230700001)(8936002)(106356001)(68736007)(36756003)(65806001)(105586002)(66066001)(50466002)(478600001)(11346002)(386003)(53546011)(316002)(16576012)(5024004)(14444005)(486006)(446003)(64126003)(47776003)(6486002)(3846002)(6116002)(2906002)(31686004)(65826007)(956004)(2616005)(5660300001)(65956001)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR07MB4912; H:[10.88.100.222]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjZQUjA3TUI0OTEyOzIzOkV2MGZYZDhEajN3bmVCb0NRWVViMDVOS0xZ?= =?utf-8?B?Vm1kYVREQXk4eGFjM2wrREwvbU4vN2JSRmJXdkszdXhTd2xuTFVlMzF4ejdE?= =?utf-8?B?Zmw0dWNuTnpNY1BXajBUWEcwaFhOMVBId29vRzhQNk9NbTBsUUVIMG9NeGVr?= =?utf-8?B?Q2pVSHNYbU5rK2VTcXpPZ3dod2NZK2crUWh5dXM5T05sTWxWdTRaQStBQXhK?= =?utf-8?B?V0lPVktQTWdTNTNYVmhpcnU1WC9iWWR1L2xheVIxRDArdlpoRkRSem1VQ2pJ?= =?utf-8?B?UnBQL1k4RHlQekYrWlpJK3AxaDNRRXV6QjRJT0Q1UDFIbGRaenI1aDhUMlAx?= =?utf-8?B?T3pzRFNpb0hIMnk2QXlNRUJrSjBFTytNZHd0OWpBZ2pXNTZGc2UxUHdVWXQ1?= =?utf-8?B?WEtZclV3SHplYUY3S3gwdWQ0ZzFaV1FPUlNLaHlKQzRRNkg3Tk1DVGh1UjNy?= =?utf-8?B?OTNPYW1RK2ZjVkV0bUZPZ2lwK0pUb0lwRURndEEwMXB2c3Ixd0R4OEhSQnZF?= =?utf-8?B?cXpFM2Y2WjFZcWlFbXlFMllndEc2Ukx2eFFsL2l0SGdBU2NCM2JBM0oyQUNa?= =?utf-8?B?TU9nS2xGQlo3Q2l2YmVOM0dIRGtMbkd5ZW1jTGJ0bkkxRDJ2blgwblRwTDZJ?= =?utf-8?B?UU1ET1ZsOGhMRS9JcmRJYVUraEJXTy8zSlJCMHozQzI5QWdRV0dmTm10Ulpi?= =?utf-8?B?eE15UGRUZDFWMC9jbHUzUFM0aFlkMURKd1Bha1krOWhteTkrek51cWhyMEhD?= =?utf-8?B?bGtFTDNWYmdpSy9yZ1BKeVpzTGw3a3pMbkVvdFNoUFZmUWpRWEt1ckFDMnFN?= =?utf-8?B?KysrVVdkQ0FoRlRTdVpzdXY4YndiR0dUYmN5VlVxY1BqM25DOTN6NmNPdUxZ?= =?utf-8?B?L1I5aDZTT1RrM0NSNDhZMGJxNGZ1OCs1SndkRmp2MlF3OHV6UDh0blh3SFgy?= =?utf-8?B?YXNhZUxMSm5xVHo4WWp2OG9Qb080RG1LN2dxZDNEM21xMHBWZHhzNFd2cHdY?= =?utf-8?B?NktaT3Fwb1N3ZGpZWVQvdmtCZHA1S3BLblpzVTN5Z3NPWWF6ZzgzbTNTdFhE?= =?utf-8?B?S1JBbG5qVkdkUWxDQ2pQQVloVkxyenBsUGQrQzZFMGh4Y3QxQW9XUW00RVVl?= =?utf-8?B?STRaT3grUVQrWE5ubTQ2S0JXQmc3UmxtR2JaWEpxbWhuMStpRnMvTkRERmxN?= =?utf-8?B?eFlYdmpaNzZnOHVoYldFd0hDVzk1WHhrMDY5UlZvMklJUjkzcTM3SjltUEY5?= =?utf-8?B?S1doM3dTQWowVWh1MmJBK2o5MVM4KzlOSEUzOTJGWWJRdmhzeUcrcU51aUUy?= =?utf-8?B?UHQvQVFzUkJaSGMyKzc2SGVHSjZ5ZXZwZVJvbWc4d2l2UnFjVnorNDRUTU80?= =?utf-8?B?c0hzcHVyVHI2S2M1Y1dLNERpN2F6WXFVMUpnelp0N1dNdTF4VGZMUzRiRlFO?= =?utf-8?B?LzVMVjRrSUFsK0hUUzdQQ1kyZG1BdHgya0xVTDNhalBLZkNsdkprWVJrNXdM?= =?utf-8?B?Z3JvTW9pTmFmYWs1RFFsWUs2UzBpSy9DNm8yc1RnMzMxL1hGVFJZaWVuU3RQ?= =?utf-8?B?L21zQXZneHhydklnaURNbVp0VFdpZUV6eDVoanlnbTZ5QWFoUnpEZmVGSVA0?= =?utf-8?B?aENYc25XK3hxMXNaN1RobXlFTUtndWtHZ2FseStZdk04U2ZpNUtHbVdEYlJ0?= =?utf-8?B?UitlVEY5LzlWMm9WVkpEQ3p5S1VLNHBqMlNqb0tnR3hFWDY5T2dzbTZnMjdy?= =?utf-8?B?S1BiYkZaVVNvbjFsR0ZJT3VsZ1FWUms5elloQ0JoSzhSNkdBeStBaS9uR2Zu?= =?utf-8?B?R0laL1hMdDErT1llNmxKcWFLSTJXMmUxUkFiNUhOM2RTS1J5Q3p1NHN6b3dX?= =?utf-8?B?cWJ2b2RSOGtleDRabHBsOUg5WVdwTlJXMUFENlYwSzZUcGt1TWFTNE9vWDY3?= =?utf-8?B?NHdDYVZ4eW8zT2VkVks2eVBtOUxBRS92NTVkR2ZNM1c0TTNVbGo2KzYzczJC?= =?utf-8?B?M3lVamozd2IweE0rdGhia2llWWZYS0RGZ0h1OTJmb2hWSGE5eTFKWkRVMmFp?= =?utf-8?B?eXNaK3VScWVsczNmeU9SVGJleGVMY2JZQjB3RzNIdTE0WGMzalg0RlZQcGJP?= =?utf-8?B?Wnc9PQ==?= X-Microsoft-Antispam-Message-Info: 00dLTmxybCWGzhmiINoqmaAiVIgopdecLG/B+3bOIX58PNP58hlBaJr+gFgytDzUNBnRDxUQmXeC7li6gHL34aRekS7A7dPTemmirSLMbxTlISN8+szyxlUvGFsMltndYoIUqzVoTIitPhd2DQxT2jBMzieDfne8LNGi5QKT7i2Jgv4MSZhVUf+S40u5dL5981j3Hhjsv6M95pENqSyijV/xvJY8yl5pZW75pxC3DFomLxaliLz1EdF+bB6NPNBp+vzPZe8EG3oCARrFGwEw0rRqiBFE7tnMwYmjRIjVEw4UdbvMTYZB0hiUhcA11f8ohrnjh92XEHFBuGoQT23BdwLLvKFWvTJta0QwXEEhrbg= X-Microsoft-Exchange-Diagnostics: 1; SN6PR07MB4912; 6:076tJ7w1I+/GUhC0lUu3wDktfQ65ouXnrioXQW5+OgcbF8KS2aIYTqt+YvTB6RS26p0+RI5Dc0m0l29pHKn1LrcTPBVZA9sd2mTc7ErKkHNOeRYaaNnXLInNvLCACu4QfmJ8OjPXokhEBreGyYTd57ZEZ3iEh3x6+waO3jJPGpqSZaomO3t72rERr3KWx4tKyFO6RqFvby5npb6iIMuhxmga1jKVjQE0aXOIb/z0eyTHbtzW++p0VJzibFMl5y3rPhZHCfRDZBlyKnQPT/ayrSfB4D8n35GS8MDKOtqm3HjHzbTGwlKebHRtQDhBl3WqvYQuTYsEmOIrcEiAHj3zJlB9LCKDwp19Un4Q3lyE9MiusRaI1MEenxFjl5LkBY4vkuI/1Ih9ci3iK6gl8hIAblXTGQIUA5mRSiAtIVGwz3E0zbmpJGIaIdz0lRYGP1q6ASdhbEeqTgfk68zpYvGp/A==; 5:Pd1PFkaKO3niIssZ+W9mFOYZp7l5Q6YFitHEhcrXsqTOGLYtPDCPAHCe2XEcl1Bc4FhxvgZ072KpjalFVs4ZpzsiP+IqQlZQ3BvVnohacoc3GaSWyhFd6MuBRMZW0o34NUZ5vP61noJFiUMbIBXk0RAFRVkiVHsXGfk9M40UTQM=; 7:Jxh7h0GYs5j6/YjQcX0knCaas4ftn5Wc8nTjFRKy0OAC43Ndgkv4zyjW8t32XVa7uy4+vlis62VHttNPiq4GWYR0L/2dvt1BSlUIo/YX2UmodstLbIw5Nhvxhjb83zltW+DXpMnysAJ8ems4b7VvbWLTQGkjyV+PUgh8ub9Pv4NXP5ZlclRA/h267ONBWkloCjWx7aia5BvhVF6L9Q7pdsXP28ROCPy79s6ZCYds5912QYwuKOoSRYa1eF2FKUF6 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2018 12:40:57.7755 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4b96be15-4cfc-4144-9517-08d6119a8089 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR07MB4912 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: Mon, 03 Sep 2018 12:41:02 -0000 Hi Konstantin, Few comments. Please see inline. Thanks, Anoob On 24-08-2018 22:23, Konstantin Ananyev wrote: > External Email > > This RFC introduces a new library within DPDK: librte_ipsec. > The aim is to provide DPDK native high performance library for IPsec > data-path processing. > The library is supposed to utilize existing DPDK crypto-dev and > security API to provide application with transparent IPsec processing API. > The library is concentrated on data-path protocols processing (ESP and AH), > IKE protocol(s) implementation is out of scope for that library. > Though hook/callback mechanisms will be defined to allow integrate it > with existing IKE implementations. > Due to quite complex nature of IPsec protocol suite and variety of user > requirements and usage scenarios a few API levels will be provided: > 1) Security Association (SA-level) API > Operates at SA level, provides functions to: > - initialize/teardown SA object > - process inbound/outbound ESP/AH packets associated with the given SA > (decrypt/encrypt, authenticate, check integrity, > add/remove ESP/AH related headers and data, etc.). > 2) Security Association Database (SAD) API > API to create/manage/destroy IPsec SAD. > While DPDK IPsec library plans to have its own implementation, > the intention is to keep it as independent from the other parts > of IPsec library as possible. > That is supposed to give users the ability to provide their own > implementation of the SAD compatible with the other parts of the > IPsec library. > 3) IPsec Context (CTX) API > This is supposed to be a high-level API, where each IPsec CTX is an > abstraction of 'independent copy of the IPsec stack'. > CTX owns set of SAs, SADs and assigned to it crypto-dev queues, etc. > and provides: > - de-multiplexing stream of inbound packets to particular SAs and > further IPsec related processing. > - IPsec related processing for the outbound packets. > - SA add/delete/update functionality [Anoob]: Security Policy is an important aspect of IPsec. An IPsec library without Security Policy API would be incomplete. For inline protocol offload, the final SP-SA check(selector check) is the only IPsec part being done by ipsec-secgw now. Would make sense to add that also in the library. > Current RFC concentrates on SA-level API only (1), > detailed discussion for 2) and 3) will be subjects for separate RFC(s). > > SA (low) level API > ================== > > API described below operates on SA level. > It provides functionality that allows user for given SA to process > inbound and outbound IPsec packets. > To be more specific: > - for inbound ESP/AH packets perform decryption, authentication, > integrity checking, remove ESP/AH related headers [Anoob] Anti-replay check would also be required. > - for outbound packets perform payload encryption, attach ICV, > update/add IP headers, add ESP/AH headers/trailers, > setup related mbuf felids (ol_flags, tx_offloads, etc.). [Anoob] Do we have any plans to handle ESN expiry? Some means to initiate an IKE renegotiation? I'm assuming application won't be aware of the sequence numbers, in this case. > - initialize/un-initialize given SA based on user provided parameters. > > Processed inbound/outbound packets could be grouped by user provided > flow id (opaque 64-bit number associated by user with given SA). > > SA-level API is based on top of crypto-dev/security API and relies on them > to perform actual cipher and integrity checking. > Due to the nature of crypto-dev API (enqueue/deque model) we use > asynchronous API for IPsec packets destined to be processed > by crypto-device: > rte_ipsec_crypto_prepare()->rte_cryptodev_enqueue_burst()-> > rte_cryptodev_dequeue_burst()->rte_ipsec_crypto_process(). > Though for packets destined for inline processing no extra overhead > is required and simple and synchronous API: rte_ipsec_inline_process() > is introduced for that case. [Anoob] The API should include event-delivery as a crypto-op completion mechanism as well. The application could configure the event crypto adapter and then enqueue and dequeue to crypto device using events (via event dev). > The following functionality: > - match inbound/outbound packets to particular SA > - manage crypto/security devices > - provide SAD/SPD related functionality > - determine what crypto/security device has to be used > for given packet(s) > is out of scope for SA-level API. > > Below is the brief (and simplified) overview of expected SA-level > API usage. > > /* allocate and initialize SA */ > size_t sz = rte_ipsec_sa_size(); > struct rte_ipsec_sa *sa = rte_malloc(sz); > struct rte_ipsec_sa_prm prm; > /* fill prm */ > rc = rte_ipsec_sa_init(sa, &prm); > if (rc != 0) { /*handle error */} > ..... > > /* process inbound/outbound IPsec packets that belongs to given SA */ > > /* inline IPsec processing was done for these packets */ > if (use_inline_ipsec) > n = rte_ipsec_inline_process(sa, pkts, nb_pkts); > /* use crypto-device to process the packets */ > else { > struct rte_crypto_op *cop[nb_pkts]; > struct rte_ipsec_group grp[nb_pkts]; > > .... > /* prepare crypto ops */ > n = rte_ipsec_crypto_prepare(sa, pkts, cops, nb_pkts); > /* enqueue crypto ops to related crypto-dev */ > n = rte_cryptodev_enqueue_burst(..., cops, n); > if (n != nb_pkts) { /*handle failed packets */} > /* dequeue finished crypto ops from related crypto-dev */ > n = rte_cryptodev_dequeue_burst(..., cops, nb_pkts); > /* finish IPsec processing for associated packets */ > n = rte_ipsec_crypto_process(cop, pkts, grp, n); [Anoob] Does the SA based grouping apply to both inbound and outbound? > /* now we have group of packets grouped by SA flow id */ > .... > } > ... > > /* uninit given SA */ > rte_ipsec_sa_fini(sa); > > Planned scope for 18.11: > ======================== > > - SA-level API definition > - ESP tunnel mode support (both IPv4/IPv6) > - Supported algorithms: AES-CBC, AES-GCM, HMAC-SHA1, NULL. > - UT [Anoob] What is UT? > Note: Still WIP, so not all planned for 18.11 functionality is in place. > > Post 18.11: > =========== > - ESP transport mode support (both IPv4/IPv6) > - update examples/ipsec-secgw to use librte_ipsec > - SAD and high-level API definition and implementation > > > Signed-off-by: Mohammad Abdul Awal > Signed-off-by: Declan Doherty > Signed-off-by: Konstantin Ananyev > --- > config/common_base | 5 + > lib/Makefile | 2 + > lib/librte_ipsec/Makefile | 24 + > lib/librte_ipsec/meson.build | 10 + > lib/librte_ipsec/pad.h | 45 ++ > lib/librte_ipsec/rte_ipsec.h | 245 +++++++++ > lib/librte_ipsec/rte_ipsec_version.map | 13 + > lib/librte_ipsec/sa.c | 921 +++++++++++++++++++++++++++++++++ > lib/librte_net/rte_esp.h | 10 +- > lib/meson.build | 2 + > mk/rte.app.mk | 2 + > 11 files changed, 1278 insertions(+), 1 deletion(-) > create mode 100644 lib/librte_ipsec/Makefile > create mode 100644 lib/librte_ipsec/meson.build > create mode 100644 lib/librte_ipsec/pad.h > create mode 100644 lib/librte_ipsec/rte_ipsec.h > create mode 100644 lib/librte_ipsec/rte_ipsec_version.map > create mode 100644 lib/librte_ipsec/sa.c > +static inline uint16_t > +esp_outb_tun_prepare(struct rte_ipsec_sa *sa, struct rte_mbuf *mb[], > + struct rte_crypto_op *cop[], uint16_t num) > +{ > + int32_t rc; > + uint32_t i, n; > + union sym_op_data icv; > + > + n = esn_outb_check_sqn(sa, num); > + > + for (i = 0; i != n; i++) { > + > + sa->sqn++; [Anoob] Shouldn't this be done atomically? > + sa->iv.v8 = rte_cpu_to_be_64(sa->sqn); > + > + /* update the packet itself */ > + rc = esp_outb_tun_pkt_prepare(sa, mb[i], &icv); > + if (rc < 0) { > + rte_errno = -rc; > + break; > + } > + > + /* update crypto op */ > + esp_outb_tun_cop_prepare(cop[i], sa, mb[i], &icv, rc); > + } > + > + return i; > +} >