From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0085.outbound.protection.outlook.com [104.47.42.85]) by dpdk.org (Postfix) with ESMTP id 42F7E2C00 for ; Thu, 31 Aug 2017 12:52:31 +0200 (CEST) Received: from MWHPR03CA0056.namprd03.prod.outlook.com (10.174.173.173) by CO2PR03MB2262.namprd03.prod.outlook.com (10.166.92.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.9; Thu, 31 Aug 2017 10:52:29 +0000 Received: from BN1BFFO11FD001.protection.gbl (2a01:111:f400:7c10::1:142) by MWHPR03CA0056.outlook.office365.com (2603:10b6:301:3b::45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.9 via Frontend Transport; Thu, 31 Aug 2017 10:52:29 +0000 Authentication-Results: spf=fail (sender IP is 192.88.158.2) smtp.mailfrom=nxp.com; monjalon.net; dkim=none (message not signed) header.d=none;monjalon.net; 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 BN1BFFO11FD001.mail.protection.outlook.com (10.58.144.64) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1385.11 via Frontend Transport; Thu, 31 Aug 2017 10:52:28 +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 v7VAqNkV019666; Thu, 31 Aug 2017 03:52:24 -0700 To: Thomas Monjalon CC: , , , , , , , References: <7834b3bd-0800-500c-1c89-3b89e2eb47fa@nxp.com> <2166799.Q9jkndJmdM@xps> <48311141-8bb2-d816-bac8-8a5bb3fd7dee@nxp.com> <7410549.rg854U5vhU@xps> From: Akhil Goyal Message-ID: <874c2bd0-d097-5082-8a9d-1f9341505ac6@nxp.com> Date: Thu, 31 Aug 2017 16:22:22 +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: <7410549.rg854U5vhU@xps> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Matching-Connectors: 131486503486986874; (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)(39860400002)(39380400002)(2980300002)(1109001)(1110001)(339900001)(24454002)(377454003)(199003)(189002)(43544003)(230700001)(33646002)(47776003)(106466001)(65826007)(5660300001)(86362001)(8936002)(31696002)(65806001)(65956001)(97736004)(561944003)(5890100001)(76176999)(110136004)(53376002)(23676002)(498600001)(54906002)(53546010)(6306002)(2906002)(105606002)(189998001)(50986999)(6246003)(54356999)(81166006)(966005)(229853002)(8676002)(356003)(31686004)(53936002)(305945005)(4001350100001)(36756003)(64126003)(104016004)(4326008)(81156014)(68736007)(77096006)(50466002)(83506001)(626005)(2950100002)(8656003)(85426001)(93886005)(69596002)(6916009)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR03MB2262; H:az84smr01.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD001; 1:m7Ms9kS/n1Z58nr6wsGJipXcppA3Ns1cs6Sm4TrfLTBLHCb2AvKAbvyoQ+ey9Eqn7GwKZwmcSvX2p9UCsJUHSu6Wunz+3Mf/vyaFxFTjqkMlYf3VCmN/YaUIEtPdgmbC X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7d2d3c3b-3b37-4fa2-391b-08d4f05e5f8e 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:CO2PR03MB2262; X-Microsoft-Exchange-Diagnostics: 1; CO2PR03MB2262; 3:XnrkfX0qDr5/SDKsIleHzlJZ2X1c3ruO8VvZHD9M1J44Hninq8ZZ1ZtsFg3wZ3r2aVFmWWO60IiitQPSvwUzeWU2NMMq0NFbjqBiEU5Ok3g11Sfxmr8EmNrW3x5d4jYwHudh2XOVFZ04keAK6lEXOCSau68t6Oo7rkXAwvhJ1OX+IsLH8BzU6/4ZMLJfrwY7TRSWWyoYptHxdaYf/QT5BvL2KgM7oblYhQHvZknoBNXoU2SmggbAv7IWc8gZie/dypHLMvE2DFfXXnr5yV2Do8JpHVS3OVXH0yrQNwPFFiuKjsXmMo+oK9dp+loFVYhQHygTEXukJZjhR1PPqsICtw==; 25:3MFvnQzhUZsDKP9kY96nsRDhskNpQPRzT72Y986p6dsgM+2xSvGCwU1WhLOapkHwABCIZCgVT72QQoMNffZ3FvrYjLlCt5QdiGy7+gZr1739Y+YJdhGtujmAFev3ksxQmCaxZ25xn5T9BHbJV61DcHZr5SJ6kAkEN/Lba7PTn//qbl8Rm4BQpF46OKWcSfr//cXUslg8i2RGLzw9h6pytABa0IFH8N0XAlQtW39oTzW7fMOB3eEJDL+eJBjiWf6S5Oy6rdD/aem4MjafRvdpUhXJpV+m9jRr5qe6bvg3SuRneqPDaCx4V+ZHWpeqAD/53kwIqGP8qY1qh087Sa83hQ==; 31:ge5ehQ7j4gLRO8K8efgt1dsLeVqMwphoTi496d3FmEvHLUe4rsxItZbpLwO0xBg7u0CP3LUMbuQCWzKquuzPbq+y8nVZvd105FzBJeNy5Pm9QbAdXYslSXe7EUzbFsRFbOqVSvKh16PYNNlCHcjd0H3TaXL17+28fZ9tinbqlHflZ2+xmRukRMniRS2NN5w9+s8USHNzZWrhtrbp5/fe21wmwl6ehZ81e+HJ4JxKQZ0= X-MS-TrafficTypeDiagnostic: CO2PR03MB2262: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(17755550239193); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6095135)(601004)(2401047)(8121501046)(5005006)(13018025)(13016025)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(6096035)(201703131430075)(201703131441075)(201703131448075)(201703131433075)(201703161259150)(20161123561025)(20161123563025)(20161123556025)(20161123565025)(20161123559100)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CO2PR03MB2262; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(400006)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CO2PR03MB2262; X-Microsoft-Exchange-Diagnostics: 1; CO2PR03MB2262; 4:bwQMYQQx37C/11MvDT+TWpCnN8bB8Ah5kWOkuF6Eow6sU4NaGN2V8sHzqJFspO1PBYiQ5IdyuK7gYcgzy7/6/b2RFnOIUaA4u8EtnnmJAkuJQeOFF6+Hnamocj4eusgx9X7ZbeVZKioSsnjpTdTHmK8l7o2Lno68T9RGwT7Fe9SqOuKD/oHnwCBrZLZEHUwTRfdY3OahRhthGPXzwDKUZW2gqPSVJzqjij9YAnDpk7L3fkMFgEdX9NkBF4rxbjlIG4U2GYZYvAlQ8iADuGYTn0xVeybNlhtDHu7LgR7NIyEJqGOVqNa7C0qWiiVryNhmbKsJeDtbdnsseAxybv7Bag== X-Forefront-PRVS: 04163EF38A X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDTzJQUjAzTUIyMjYyOzIzOkdRdndET1h4NUxHbE1WQUFsSVZrc3hsdkkz?= =?utf-8?B?ZENkY1AzK3dCSm81L0ZxMGJkRWpqNTN5cUhyTURsMHZmNDNWM2FqYWRpTFBo?= =?utf-8?B?b1FKSTgybTRJQjVQNkFwZjhWSE1sSnJ0SG5zc21NNXU1eG5GdXNRb0s4L1Fh?= =?utf-8?B?akRubXgrUmRwVEQybVJMazRETklCTjF0S2g4NnNXV1VlRldsMWdjeUtVaXc0?= =?utf-8?B?b2lYU3NlN1J0dVRYYmFOQ3gycjBPa0gwK01mU1pxaTI5QXdLLzNFaS8xdUZX?= =?utf-8?B?NkdFN2lKaGNjc3RIaWRRdmljMEVqbnFWay9LL2daQVVLSEN2Q050VDNNa0Jn?= =?utf-8?B?QTd1c0ljK2NCd2wzSDk1TU85elJQNnk3UzlydWJYc1E1eFpIeDh1dnNoRzVN?= =?utf-8?B?UWdaNFMyQzdBcXJuN0hHb1hFYXM4Y1I2bmZoN3BzZ013RlJRM1IwaXZRZDAv?= =?utf-8?B?TUh6N2pvRzR6Y0o2c3loa3dmVXMwdHUvK2JaanRFS0tNU3pTL3d3TmNuSERO?= =?utf-8?B?Q1doSzFzWTVpVkF5VTNLNnJlYVZGdVBySzZLenIvTGNrdHNQMFF4cmZIekJY?= =?utf-8?B?V3lCTis1N1E2Tm9sdktwZXpoalV0N2VLUUNhU2gvUTkrQUJqMVhXK0hMYzVq?= =?utf-8?B?UVN1K2UrU2o0WDMyeDRMcVdTUUd6OERuNTlCOS9sSlJRbUZ5K20xQ1pBOGlm?= =?utf-8?B?ejZsdUt1TVdJZTN3aW1rZUFTbEVYRkE4eVlEczl6bThyVVpMRStPemlCNHo0?= =?utf-8?B?d1pKaTYva0dXOHl0WG92YnowT01VR3lsdGJ6V0ZxTnZXaFlNN052YnU2blY1?= =?utf-8?B?VDBkd0gweGVxT3M3WjhUTnJ1cHFtbzZBOTNDc3dHa2pxRU9qU1Rpa29WYUZi?= =?utf-8?B?YkFUR0dXWnlrYjNEZGc1UXUyWDdhK1J2N0R6dEVVNEFOcEZReHZWRkRrYmJO?= =?utf-8?B?VmRNZGNjN1RnSFRYZFBpYmV1RW9DNmg1dHlWMzlCblVzYWhRRnYzbHBGVDgy?= =?utf-8?B?NjJBdFUzYjRkUXNLcWFMMjRxSk1rajlxbExNeXJET29TL3g4VUlqREh1RHc0?= =?utf-8?B?RkFCZEY0b2xEV3haNk1HN0lvYjNjL3NqWlJVL1FXeVFIVXlDeEg3OFJlZ1o4?= =?utf-8?B?dTZYMlQrTGhBcE5NVHlGLzNSWnYxVDZoRnJ1YkRtTzVzM2RSUWpsNUx5RUhT?= =?utf-8?B?TWRpOE1BZmVDOFZCbC96eWxJcHlIVTZUWVRaWDE0S01FSW9TMEUyZ01tOEtv?= =?utf-8?B?cU5Rak16ZUlFbHhJTVFwbjBXdmhSekl3OXhLL05vT3BSaGl2WUtJRWhMTHlF?= =?utf-8?B?cnRwYVBicUhLUkFMeGpWQnRPdHBwR3NsUXlLS0RWVDc5REpXZVVZQWJPdW4z?= =?utf-8?B?WTlUYWtRcE03WkdUNUNPejNhTzdXZzJMSFNLSnNzcGVvYjN3dFJyQnFaaUpD?= =?utf-8?B?VXkxVkxHa3RyOC8wa1IrczFuYWRCUW9peWFPSXJOaFhmYmJRSkhzTHhtSVds?= =?utf-8?B?UzJGVGxkQ3B3bnlSWHdod1BPd0h5bmduMU9hbVRONEdvZy9MblZyK0ZuWkR0?= =?utf-8?B?Rk5IVnhRazNHYkhRc3U2UDFZb3c0TW1VMTZZTG5QSy9hV0x5QlZWKzVSc0Q4?= =?utf-8?B?aDFjbHg0V2xrdVFJaGRBbjkrNEFQQmhjTUFUUUlTd0dHcmltTGJNNE1lMEVk?= =?utf-8?B?SkFwN0p2QnA3aDJVMVpxU29hQXM2VXRCcHZQaGpFVFp5QzRXcHRxQ3FtNXQv?= =?utf-8?B?RUVXRmVKZlZYT3MrcEZhRmM2eTNOVHFsMGMwVXFTMmZUMW1BYUNrWjFlQnFI?= =?utf-8?B?SDdGTFlUM050U3FUM2FhVWw2aTVaMWVVMEFYdDh3N1VuOHhBc2ZJNDdTYkZX?= =?utf-8?B?M0xXVGovZE9raFlkUFhyWGplZ0x3bnp1anhHbldYdGhIVUgwSFJybWcxbUha?= =?utf-8?B?N1dsUzg5UjhIaVpTSklHbW1DWnFZdVk3cFp4N1lQaHFRWlJ5R3RhQk9VY3Z3?= =?utf-8?B?cU0zaDFQWjk3Qi8rNmgzZHc4NHFacVhtTEFxcHUxYVZaeDVtOW5FOHBLeFRx?= =?utf-8?B?RHRqam5GaGtiTW5iNHhkQ2ZNQnZBTkdFamh4S2ROekpiK3hUL2xNTi9PUTB5?= =?utf-8?Q?O3MhC06ecEFzZZYaoQVQn4I=3D?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR03MB2262; 6:i9aHGggWZLM8PG4jDdnH3i1SfycYlHWTIfbAvifOttk3RewOTHDiedhQkavfOIQcH8ja99T788ti2hgF1yzrEPG/0k/1hYqhX9RHgsQbVAw7MEVcvM8ABFfhA8KKIPbIo8YV4CckP3Jo9CFPe3tCED3K2xqt4QgTVu1DggdxeU6UBaYbFp5j4qGNSHo1GzI+/nxPn2ayqrGDPES0E/+1+YQFyMfIuVhW0TNj0sJSmhnfjijFKwc1FOragDMAXQ8kC2Xz6JnpEvcMkRonhlfhPZWe+pd5Opbm+eRbryHv3GlIXicvtrmpOxnOeYYGJt3xqPDn+u3AugsKdzJk6frEwg==; 5:k0oYqcWBAcjlZwa00mzorXe4RRhPt45rPgsi4ZwPMPPjVQCxy83OzGmcogRzEbIHXDO5nTEXb75aJ4YQegxhH9LeU3sfkfGbJKAexb1ntzvBhA4f8fJ8dWinC0XaBKatsmVsMup0iUAGojOQaKQD4A==; 24:yQZfWkJLGrZtNGaog7jR6iYRbcDCXi41TMbjkx6KOT44TFZsHXZ0U0ZXlyc8O5FTIGFqvKEZaiQ2u/ivbRAxE8bCrz5BAol3TRTIsmhHuM4=; 7:+KKKP/jkMaOo1+4zDb1aOWtAzW+2FQTo/JfrV5SVWUN2hOND560Dkx9TdR4VtYj5nLR6859GKqFo5o2KJFxEAS9kooAzWsl0Q/ebiguF99sRfM7LGeBLW2EVabxzFCK/CCsTifK4lFV2ZlyLC7iD6EjQwRAxWs8RODwZURJ/4D+INhlqBMXOsfb+kLY7N0Fgyy83QudqPJ72x1OYjhYV+fw05xkWrkuoLSNJI3x7oWQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Aug 2017 10:52:28.2930 (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: CO2PR03MB2262 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: Thu, 31 Aug 2017 10:52:32 -0000 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: >>>> These are very similar to what Declan proposed with a few additions. >>>> This can be updated further for other security protocols like MACSec and DTLS >>> >>> You should avoid referencing another proposal without >>> - link to the proposal >>> - summary of the proposal >> The link is not mentioned in the cover note but the patches are sent in >> reply to the same thread that I have mentioned. If we see the complete >> thread, then there should not be any gap. >>> >>> [...] >>>> Now, after the application configures the session using above APIs, it needs to >>>> attach the session with the crypto_op in case the session is configured for >>>> crypto look aside protocol offload. For IPSec inline/ full protocol offload >>>> using NIC, the mbuf ol_flags can be set as per the RFC suggested by Boris. >>> >>> Again a missing reference (link + summary). >>> >>> Even worst, the RFCv2 references this v1 without copying the explanations. >>> It is too hard to track, or maybe it is cryptic on purpose ;) >> Same comment, patches are sent within the same thread. >> Please let me know what is not clear with the thread. >> >> Also, I would take care about this comment, that I need to copy the >> content of previous versions, in my future patches. >> >> As this was an RFC series of patches, the content may not 100% stable, >> and things may get finalized during the course of development across >> Intel/NXP/Mellanox and may be others. >> >> As per my understanding all the information is there in the complete >> thread and nothing looks cryptic to me. > > I am sure nothing looks cryptic to you :) > But you are not writing it for yourself. My feedback is that it would be > easier to read if you summarize the whole status in the same cover letter. > You are free to consider my feedback or not. > >>> [...] >>>> Now the application(ipsec-secgw) have 4 paths to decide for the data path. >>>> 1. Non-protocol offload (currently implemented) >>>> 2. IPSec inline(only crypto operations using NIC) >>>> 3. full protocol offload(crypto operations along with all the IPsec header >>>> and trailer processing using NIC) >>>> 4. look aside protocol offload(single-pass encryption and authentication with >>>> additional levels of protocol processing offload using crypto device) >>> >>> I feel these 4 paths are the most important to discuss. >>> Unfortunately there are not enough detailed. >>> Please explain the purpose and implementation of each one. >> Yes these are 4 paths which can be used for IPSEC. >> 1. Non protocol offload(RTE_SECURITY_SESS_NONE) - the existing >> application works on this path, the crypto devices perform the crypto >> operations without protocol knowledge. > > This mode is when using cryptodev API, right? > Are you proposing to use rte_security as a simple wrapper of cryptodev > in the mode RTE_SECURITY_SESS_NONE? No, rte_security is not a wrapper over cryptodev. It stands parallel to cryptodev APIs. RTE_SECURITY_SESS_NONE denotes that there is no security session involved and user will be using the existing functionality i.e. non-protocol offload and use crypto devices for crypto operations. > >> 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. > 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 > Is there direct Rx/Tx involved in this mode? No the packet will come to the application and will add/remove relevant headers and then send the packet to the appropriate eth dev after route lookup. > >> 3. full protocol offload(RTE_SECURITY_SESS_ETH_PROTO_OFFLOAD) - This is >> same as 2 but with protocol support in the ethernet device. > > Is there direct Rx/Tx in RTE_SECURITY_SESS_ETH_PROTO_OFFLOAD? No, there should not be direct rx/tx as the application will do route lookup and send the packet to relevant ethernet interface. > >> 4. look aside protocol offload(RTE_SECURITY_SESS_CRYPTO_PROTO_OFFLOAD) - >> This is same as 1 but with protocol support in crypto device. > > Who is responsible for Rx/Tx in RTE_SECURITY_SESS_CRYPTO_PROTO_OFFLOAD? The packet is returned back to the application as in the case of non protocol offload. But the application doesnt need to take care of the headers and other protocol specifics. It just need to forward the packet to the relevent eth dev after route lookup. Please refer to RFC v2 of the proposal it has more details in the header file rte_security.h and the implementation using the ipsec-secgw application. http://dpdk.org/ml/archives/dev/2017-August/072900.html > > [...] >>>> The application can decide using the below action types >>>> enum rte_security_session_action_type { >>>> RTE_SECURITY_SESS_ETH_INLINE_CRYPTO, >>>> /**< Crypto operations are performed by Network interface */ >>> >>> In this mode, the ethdev port does the same thing as a crypto port? >> >> not exactly everything. In this mode, only cipher and auth operations >> are performed by the eth device. No intelligence about the protocol is >> done. This is similar to what the current implementation do with the >> crypto device(Non protocol offload). > > Are you saying no but yes? > I say "ethdev port does the same thing as a crypto port" > You say "similar to what the current implementation do with the crypto device" This is said so because the crypto device may also support protocol offload. > >>>> RTE_SECURITY_SESS_ETH_PROTO_OFFLOAD, >>>> /**< Crypto operations with protocol support are performed >>>> * by Network/ethernet device. >>>> */ >>>> RTE_SECURITY_SESS_CRYPTO_PROTO_OFFLOAD, >>>> /**< Crypto operations with protocol support are performed >>>> * by Crypto device. >>>> */ >>> >>> I guess the difference between ETH_PROTO_OFFLOAD and CRYPTO_PROTO_OFFLOAD >>> is that we must re-inject packets from CRYPTO_PROTO_OFFLOAD to the NIC? >> >> yes > > OK > Who is responsible to re-inject packets from CRYPTO_PROTO_OFFLOAD to the NIC? Application will do the forwarding after route lookup > >>>> RTE_SECURITY_SESS_NONE >>>> /**< Non protocol offload. Application need to manage everything */ >>>> }; >>> >>> What RTE_SECURITY_SESS_NONE does? It is said to be implemented above. >> >> It is non protocol offload mentioned above. > > How is it different from using cryptodev? No it is not different. It is just to mention that there is no security session involved and the application will use the cryptodev. > -Akhil