From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0058.outbound.protection.outlook.com [104.47.32.58]) by dpdk.org (Postfix) with ESMTP id 95AD47CBC for ; Fri, 8 Sep 2017 13:13:05 +0200 (CEST) Received: from BLUPR0301CA0005.namprd03.prod.outlook.com (10.162.113.143) by DM5PR03MB3321.namprd03.prod.outlook.com (10.174.241.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.12; Fri, 8 Sep 2017 11:13:04 +0000 Received: from BY2FFO11FD006.protection.gbl (2a01:111:f400:7c0c::190) by BLUPR0301CA0005.outlook.office365.com (2a01:111:e400:5259::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.12 via Frontend Transport; Fri, 8 Sep 2017 11:13:03 +0000 Authentication-Results: spf=fail (sender IP is 192.88.168.50) smtp.mailfrom=nxp.com; caviumnetworks.com; dkim=none (message not signed) header.d=none; caviumnetworks.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 BY2FFO11FD006.mail.protection.outlook.com (10.1.14.127) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1385.11 via Frontend Transport; Fri, 8 Sep 2017 11:13:03 +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 v88BCuls029809; Fri, 8 Sep 2017 04:12:57 -0700 To: Jerin Jacob , Radu Nicolau CC: Thomas Monjalon , , , , , , , , , , , , References: <7834b3bd-0800-500c-1c89-3b89e2eb47fa@nxp.com> <7410549.rg854U5vhU@xps> <874c2bd0-d097-5082-8a9d-1f9341505ac6@nxp.com> <5392171.j1FdNZENvz@xps> <94a4b6b5-a80a-9884-244a-02131c695eff@intel.com> <20170906155319.GA30919@jerin> From: Akhil Goyal Message-ID: <2ff5080e-2806-84ed-4e61-c982f854ab94@nxp.com> Date: Fri, 8 Sep 2017 16:42:56 +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: <20170906155319.GA30919@jerin> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Matching-Connectors: 131493427834698491; (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)(39380400002)(39860400002)(2980300002)(1110001)(1109001)(339900001)(43544003)(377454003)(199003)(13464003)(24454002)(189002)(93886005)(31696002)(86362001)(50986999)(76176999)(189998001)(54356999)(36756003)(104016004)(561944003)(5660300001)(8936002)(7416002)(65826007)(81166006)(81156014)(356003)(8676002)(31686004)(966005)(106466001)(8656003)(53546010)(105606002)(498600001)(33646002)(4326008)(305945005)(2906002)(4001350100001)(53936002)(83506001)(50466002)(54906002)(23676002)(229853002)(65956001)(6246003)(2950100002)(65806001)(6306002)(47776003)(53376002)(64126003)(68736007)(230700001)(97736004)(85426001)(77096006)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR03MB3321; H:tx30smr01.am.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD006; 1:Pca80DBIo+Vb5x877MVXMCzBiNb0pmoZ46qvUR+X8kJ/DSmgUr98YvmAqdQ+7HAcC6q3ePFm5vw1DVlugiKNvuhufO5gN3BLpPty8j0bt5ytZkehM7TKnreYlQ0080aN X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5697dffe-0a35-42d4-599a-08d4f6aa92d7 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(2017052603199)(201703131430075)(201703131517081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR03MB3321; X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB3321; 3:DyrHo1AQ5EmsVpvC30WcKRPYPPYTB7KlmQKMbo8gg+eMD5eSSwExu+ldxCG5CtsqHZhgRtIAL3E2TUysUbmpAlPrxvWRR0zkD6Zu9z/0/ZDSYYxMJIuUwCz4rOzSSXyYLfEjMs6ZqdICVYQraAELFyz/I2pxsJGvKSRwqugxq47a03jORYAJlGPodexmPbVxOYpZVsimspM3YwYP/+jrDpGBMVwWEmIiSam/D02c0JlQ7MFv1WjGTkwooLPyKM5j14ujywTzsm0x+4eWyqBxTFLtxSLNSkq4cb1n0heWZj0YCveI7uCHCkzi+ZTVZZ3DxG1FWwnMegS8/CX+ZRPxMvy0Jo9887jap5IAKo1Wx5w=; 25:nSpNyfzY7R546yQkgNHTNz86DjfoV4jxnnFPp96TI2aLa7cGBuzURWmUNSmqwiavH9LOSSOu5wj10CdSoOQDb7FWoEO+m2OMNO0l/5SqF9a9VwediBTeHDVbd73kOyMk7lZ06U2tr8zCmRKf0GbYq/fO5elteKaPfJeuLqKJPDSztt+q27rGO1Rzo6PkVyOd9LkEoqn0lZFn67xdfTLx7hncjdkDlXdeFfIzKhAAuiVlxGXGb4E1GBxK3qvmpzwQWHTSxLtuaQ3ViNx214ENktkknGUZxUGmpADNoYQ/l9qwYRqs79H4b3IrGykCDZA25O33VOy2Mou6U5rVE1p/zA== X-MS-TrafficTypeDiagnostic: DM5PR03MB3321: X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB3321; 31:/xh2DSu5BcbTuWThqqJEaV7kqsi8+OyDY0utd7M9GkuPPuo+3VjZDKFzx8cQWrp4HhzRYbpG+wKuJ08pQN5/StbvmS7ydQQRU+gzBK0+RHpdqIRe2P/IGpjRmhaGjaaseGFXI94Lr+QvrTDz2WfkiNujkhfmXbn/TEe9cSx3jJ60mfeiYj7VAgFGG0/piiAayUctu975n9rBYmtHuYQAustFEes4znFQ7LSVxWNrytA=; 4:UNzV/Qk888lxCISpw4W0g5YwkPcomnV3KK7kjR/VRtQrPLXpRyXEaXQbOAaMmLfpD56BIjCnOaA4NfwpY9WqB0CoQq8WK5mjYan0TxqRPRDS8rXz4PD8IuT+AbdSbvyghCLFGFvbjr7W6UQqvFDh+/ivx8iNVVdGC/J9lkDUcHhpGht76X954J+yIhvVw0/NFuGW6OAnDrA6i13faUpjH7nX++UnoKkNKv9WxIrwxc4sskekkuPFnBJWSe4kgdMnEd+w+x+S2ABcvLeBSy70g00E/hD8GW6ZV5Dj2pIQ0CTVPHyE3gOocz3ywXyl0E+gcGdkGvk/KoVh5Vk89UAtB+RUuRkcXcBwgIBgbvjShD6C9vKEv7QKJZbl5H931y81PuXKkXTFpCduYaJqx2b4uA== X-Exchange-Antispam-Report-Test: UriScan:(185117386973197)(155532106045638)(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)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6096035)(20161123563025)(20161123559100)(20161123556025)(20161123565025)(20161123561025)(201703131430075)(201703131433075)(201703131448075)(201703161259150)(201703151042153)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR03MB3321; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(400006)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR03MB3321; X-Forefront-PRVS: 04244E0DC5 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTVQUjAzTUIzMzIxOzIzOlVWbHBjd0VDR3VGclo3K1ZFbzdKSkFQblVk?= =?utf-8?B?Y3pyYmtNNFNOY1JYblJta3hzMnhqekdPN0dBRkpjZThtM0p6MHhNd1VIbTln?= =?utf-8?B?QlZoRVdOTlRzMUh6NDk3ZFU1QzRCajF2UElKeUIzemFmdnhsU3pwU2RqTnp4?= =?utf-8?B?YkJzMlladzZDNnFwV1pxQjZOc3ZPUkVzN3hmVjcwbUJlZ292b3JwTHNZL2FJ?= =?utf-8?B?T1NBTk1MbDBTS0QzWEw4eFI5M1A5N09pMGdqcTBIaS9KZGRVeTU2MW5uOVZx?= =?utf-8?B?T0xqMjVwb1JZTWdGZC9wSDBxckVlWWx5WHd0MjJWaWJseEM5RUpoTWREV1pz?= =?utf-8?B?M3JCYzRGOGtUWHo0UitqTm9BaHUyNXRHQ2NhaHBvdWRnQ29QaW56TElmbmNF?= =?utf-8?B?QlhYNmNSL1A2UkdpSEFDVjhIVVpFZDRzd3ZvOUZmY2hDL2ZDK0pvZTRZT3ZW?= =?utf-8?B?QUlzd1BWVjRzN0R3dmtqNkpLamcyNkdzdzVBVGNLWE5wd3kyb2RZSXo1S1p3?= =?utf-8?B?Q001N1NENmZHTkFCRDFiYUJuU1VjZFZsN3hvRHFobFN6K2owYm9RZTJPNUV0?= =?utf-8?B?TEx4WTJyU0lHTWNXL2paNS9WaXpiRFozemx6T2QrQlBSNyszWjZ4dkhRQ0dX?= =?utf-8?B?cEhUUDVZWklJQ1FZY0JTMzVQa1BZU3BaamlzVnpWa1BGZU1Gd2VINjhCU0dv?= =?utf-8?B?eVZtRXd4WURjSWlMSHVFdFJzelc3Tk9KenNjcU0yVEZaSDRyUmQyLzJ3S0Rl?= =?utf-8?B?K0FTOGFsdGxOcmg0NjdCeGJodG1mV01RTFVWTjlRT2NpYVBteG5rTTAzbWVq?= =?utf-8?B?QlIrUzdFcWZDWFpsMjQvNnNFK0Z5Y2E3Wkd6Y2pDT3JSS3VFZEplK0J2RlZ6?= =?utf-8?B?WnNtelpZU0hRMnk2T1kwZmJ6QnAwd3lRRmJ0S0ZwUVBHV0wveGE5ZnB0VXE3?= =?utf-8?B?dW9KbnZDRGhZUm9VK1I2cWw1elhxcmxMSmRwN2ViVU1qQUtGNGNxcHl5MzJ4?= =?utf-8?B?b1BtMnFlSHdWZWpPSmtWdHh5ZUdOMFlrQ2w4cHMyY1BzU3ZIWkxUTFJGTHpB?= =?utf-8?B?MzZ0WnJDT01zNDlCUVFsRXN0alE0RFZwdGtZcjdlMk00SFdJVWRLZklzN0Vj?= =?utf-8?B?Y2kxT0xTWGk0SHBGTEoyRVZEWklWdmF0TC9vZ1JUU1laMzExUFhxcUtZN1dj?= =?utf-8?B?NGFHRDR3VGl5L1lIeWN5cmxoM05mald4NkRYQndDakd6aHlxRXVISlZxdm1E?= =?utf-8?B?Zy8rTjZsck8zUWtaQ21zT0Q3aGJNcUd5bFNTUlFSbVdWSk5BSUxvQUo0TTYz?= =?utf-8?B?WHF2NEljbE9CQlo0ZE5TOWZRbjJCSEpnbDVtTWhlN01tU1B4WVE1TFd6NGNk?= =?utf-8?B?bUdtQkx6Mk9yUzBIYTNFdVA1aWd2Yk1Ub01Zbm9FNVBRVkY0bmZGMTRnanQw?= =?utf-8?B?RjBjV0hyZ2RQUmw2S1pDWFM0SVJXVEFJczVwcllaTmpDZHp5THYzL1dSS3hY?= =?utf-8?B?c21zQUFXT3RJSm9BdmNjQ2w4Y0M0bnFMTWVBVmZjTmdXRVRCZ3VHZVZ6dEMv?= =?utf-8?B?dmxmdFROOXIzY3MweHlaZWJua2VBd1JaTWtyKzUxSUZieGNxcm1tTHZYZ2lM?= =?utf-8?B?ME9xcGFDbXA4UHl3aU5SWVB4MW9SSlhNTWFyb3gyb1lFbHF5V1cxL05JRTh1?= =?utf-8?B?d2UxVmhmdnFMby83blNTdXBRTHNDSFJGQ091ZFZKNnY4SDh6M0laT1BwbkxN?= =?utf-8?B?QUxoV09vWmw0U3VJSmszTFJlRXZvM2FHM3l3am5JWTJzZTM2V1prMDVGU0hI?= =?utf-8?B?VG5jVEpwbVhSaVpvR2RrRlV0ZGNHWE9KMzhBcFBPdzMzTWw5Sm10WnQyamhp?= =?utf-8?B?TFppb1NFeXI2SGc4cUxBMmRmYi96dTNDeDlVZnZJN09vYUdQeG9qSjFaMU0r?= =?utf-8?B?ZHZRL1BCZXNlRmJYc3ZvZ0RRVktiZE8xd0x1V2VTWHJWcmt0bUE5U0NqNjRB?= =?utf-8?B?KzhNaUJ2RXB1aVRNOUx5aDQxR2FBZjBPM2xIaURiTFR5ZTlaM1RZVC9XZ1RQ?= =?utf-8?Q?HkDE=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB3321; 6:tcuJkrhI508t5NJ+55nR3BtecepNT+zxLORKS6E7IF3RcrDXpQVG7ZTKLB6VDGWDkrZPskLYcfu5p22UXHMtgHylWKoaNcPM7HRTPQGhMV3MLjWnPdtLsGpkzbCHJwbc6Ijan0gynW3bO/ooG82H+n1w+w7XzUTqby1Pl9H0GL3FL0o+SLI1FHas1j+BtSoCXKX+yL5GE6MnVyY15MECrpn518wbHXyQ05056qxhcyLNKjJCVpm812sdasG7jTHdRUSo63D84K/6pPV3MlXInYyv4Ds9Ac8e4a5w6O8gFUMC2CcbbT4cL75mIyysc7BN46RSDdshCSkqwbObVTH2Jw==; 5:liLqnE18TDwVzSuUKBa4wQ1DLKJwyb4mSmdHW2YSKcqCjNXBSMBNUKkct72OZZtJDEjZYpjRxO1nthZCNRQsjjXxfUWtsgs6ME8Cs0XzttadYkfJwMQRtf5qmAOlRU9+1E02ocf5OmvUEqqQt3tGcJb0Ietdf01PQV49b4WNQQI=; 24:sXMQDzrNMzJudzGwxIlINb1DuWFFxkpkplZ/nJ1oIR09zAx5IOFtMq39YR+T0rRu4zjk+5q7qNDpXkzIsgsZi1pNkjBcoAy+zLEORnU13Qs=; 7:7UDXm+riu7J1Nd3ZxiMXoY7BqcCKgOnsdlOhpVor/kYKcF/9K0SYi7FcyA8jEERzQwccIdtbbwsmf0OEhJbyjc+igJ5ehuiCJ/+C3LHY67JmTeO3iBAWhQlObsv0Mw6YGZPltPixuIKvWF0VdwZM37dhvr6m+WrfMgRaJsiCl/5VpDJReZs/kz08mmywpOXzZfahvjN97UhKE1k+WzJC1aTMVFOsKWWh8okhYX//+0Y= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2017 11:13:03.2202 (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: DM5PR03MB3321 Subject: Re: [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload 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: Fri, 08 Sep 2017 11:13:06 -0000 Hi Jerin, On 9/6/2017 9:23 PM, Jerin Jacob wrote: > -----Original Message----- >> Date: Thu, 31 Aug 2017 15:09:45 +0100 >> From: Radu Nicolau >> To: Thomas Monjalon , Akhil Goyal >> CC: dev@dpdk.org, borisp@mellanox.com, declan.doherty@intel.com, >> aviadye@mellanox.com, sandeep.malik@nxp.com, hemant.agrawal@nxp.com, >> pablo.de.lara.guarch@intel.com >> Subject: Re: [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto >> offload >> User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 >> Thunderbird/52.1.0 >> >> >> On 8/31/2017 2:14 PM, Thomas Monjalon wrote: >>> 31/08/2017 12:52, Akhil Goyal: >>>> On 8/31/2017 3:36 PM, Thomas Monjalon wrote: >>>>> 31/08/2017 11:37, Akhil Goyal: >>>>>> On 8/29/2017 8:19 PM, Thomas Monjalon wrote: >>>>>>> 25/07/2017 13:21, Akhil Goyal: >>>>>> 2. Ipsec inline(RTE_SECURITY_SESS_ETH_INLINE_CRYPTO) - This is when the >>>>>> crypto operations are performed by ethernet device instead of crypto >>>>>> device. This is also without protocol knowledge inside the ethernet device >>>>> If the ethernet device can act as a crypto device, this function >>>>> should be offered via the cryptodev interface. >>>> yes this could be thought of but the intent was to keep cryptodev and >>>> ethdev separate, as this would create confusion and will become >>>> difficult to manage. >>> I think the reverse: it is confusing to do crypto operations through >>> ethdev interface. >>> If a device can do "standalone crypto" and networking, it should appear as >>> 2 different ports in my opinion. >>> >>>>> How is it different from mode RTE_SECURITY_SESS_NONE? >>>> In RTE_SECURITY_SESS_NONE - crypto device is used for crypto operations. >>>> In RTE_SECURITY_SESS_ETH_INLINE_CRYPTO - ethernet device is used for >>>> crypto operations. >>>> For details of the data path of this mode, refer to the covernote of RFC >>>> patch from Boris. >>>> http://dpdk.org/ml/archives/dev/2017-July/070793.html >>>> >>>> For implementation of this mode, see patches from Radu, >>>> http://dpdk.org/ml/archives/dev/2017-August/073587.html >>> Boris RFC uses rte_flow. >>> Radu implementation does not use rte_flow. >>> So I still don't understand the big picture. >>> Boris asked the question and had no answer. >> I'll answer here: it was an omission from my side; v2 of the will include >> rte_flow usage, derived from Boris RFC. > > > Cavium would like to contribute to the definition of this specification > as our HW supports the IPSec offload. > > I was trying to review the latest patch. But it looks like there are > multiple versions of the header file floating around. like, > > http://dpdk.org/ml/archives/dev/2017-August/073587.html > http://dpdk.org/ml/archives/dev/2017-August/073738.html > > Can some one tell which one is latest one to review? > > Previously for rte_flow, rte_eventdev specification, etc we had some > header file sign off before jumping to the RFC implementation. IMO, That > model was useful where all the vendors could make inline comments on the > proposal instead of maintaining in the draft repo. So it possible for > sending the latest revision of the header file patch on the mailing list > for the inline comments. > The RFC remained for some time, there were not many comments. so we all agreed moved to implementation. That is the point we requested for the repo. The Cavium comments came bit late. Currently I have just consolidated the patches in the draft repo and I am going rebase it and post to mailing list as well in next 1-2 days. Since, the implementation is started, we will request any subsequent comments as an incremental patches. > Akhil, > > Based on your v2 version, we could map a lot with our HW. However, there > are three top level quires for the further review. > > 1) Some HW cannot offload all types of packets(like IP fragmented > packets) and/or there may have back pressure momentarily from IPSec offload > engine (like Queue is full) etc. So in that case what is the expected behavior > a) Is it an offload driver responsibility to take care of that or > b) Is it passed to application as encrypted packets(in case of inbound) > and the application has to take or of them. > It will depend on the HW capability. If the HW is not supporting the fragmented etc packets, they will come as an encrypted packed to the application and application need to take care of them. > 2) In case of inbound traffic, What is the packet format from offload > driver. i.e > a) Will ESP header will be removed from the packet area after the > decryption. > It depend on the session action type. e.g. for inline crypto, the header will be intact. for inline proto, the headers will be removed. In any case, we need to improve the documentation. > 3) We have a few feature like, anti-replay check, SA expiry((byte/time) > notification, etc from HW/FW. So it is not clear from the specification > on the contract between between offload driver vs application > responsibility? Can you give some insight on that? Especially > the error notification scheme if it is an offload driver responsibility. > Anti-replay, SA expiry management is still in my todo list. The responsibilities will depend on the amount of offloading the HW/FW is offering. The current intent is that SA management and expiry is being managed by the applicaiton. However, SA expiry event for byte based SA will be passed by the HW/FW to application. In short, the current focus is covering the basic support only. Rest will be incremental. > This questions will help us to review your proposal and make forward > progress. > > Thanks, > /Jerin > Regards, Akhil