From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0054.outbound.protection.outlook.com [104.47.33.54]) by dpdk.org (Postfix) with ESMTP id DBDAF2BCE for ; Mon, 11 Sep 2017 20:10:49 +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; bh=ykaht5USa/8PRZMnlvxVZvSDxms1SmVUSLOJ+yxFatY=; b=b2nbsSGE/SxUPgvNupet3DbGExSVCLWccoIl+Hwl4f9sr+9RxhAQF9khLxY4XPqvrD93mMvafA7iVCfcQGdwAUqVfTCtU1WI1+74oT2p3myDtbDhXdAwNlmNJo1ROvG4l/X34DmVegq69uql0gOM5hMh/E2ZyipIiZyHcsZWN8w= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; Received: from jerin (106.201.102.0) by BN3PR07MB2515.namprd07.prod.outlook.com (10.167.4.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Mon, 11 Sep 2017 18:10:42 +0000 Date: Mon, 11 Sep 2017 23:40:25 +0530 From: Jerin Jacob To: Akhil Goyal Cc: Radu Nicolau , Thomas Monjalon , 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, pathreya@caviumnetworks.com, andriy.berestovskyy@cavium.com, sunil.kulkarni@cavium.com, balasubramanian.manoharan@cavium.com, suheil.chandran@cavium.com Message-ID: <20170911181024.GC26002@jerin> 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> <2ff5080e-2806-84ed-4e61-c982f854ab94@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2ff5080e-2806-84ed-4e61-c982f854ab94@nxp.com> User-Agent: Mutt/1.9.0 (2017-09-02) X-Originating-IP: [106.201.102.0] X-ClientProxiedBy: BM1PR01CA0073.INDPRD01.PROD.OUTLOOK.COM (10.174.208.141) To BN3PR07MB2515.namprd07.prod.outlook.com (10.167.4.140) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c1a237ce-1618-47b4-68a4-08d4f9406d6f X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR07MB2515; X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2515; 3:aXVdexO711P5bVy+l3Eo7VZbh3yoT6aA26IbwisXwf/Cbkl+M7WVgb9ikr/Km1Lmieq+Jdc4ok0sTQx1kp8/RyBA7LLIL4pnCAduYIkUnRwjKAl8ZdQS4SgE7FMYSKBwFcd4Xsw0wFYczHrfFm2qkf4XAR05dMCyDb6yOyfWeiiwabK+EROrGUpRPXs4wzrtsm0n5oBF700P77nx4kIgER52ExRglsaV7kNbP3ip5k7j7+VgkZEEp0FaiFnLV+HS; 25:t+GUgGVHQp4NCWAtyijVW+UjNhRJRlxDOveIknHc+YBcB8kZTP14HInILqT7wUbd6oBuRS8CL9kVZZkhBNcrsPQaELfD0ocLyVNiHTUxgt2w7nZf3jCY6wKfobpg11ph9MaTVvdrMIpRwCQngDBJg5TIbMQMmaY25/y7i34wkM2vZRDEarCQjESkRTpnaEcDuwoQE/j1OhtpRsr3qYsbP6vjOjTY2Gbm/Wl0W7ct0SvGkq3+RKxSzqNrBPyztRux1yg8j4MnYr0iawvSQzbtySP3Fp8eMQuoTAZpGF8yMiHtd3w008IZK0KnGRNSRmjQs64cYyukf/vpDbeiSi7VWw==; 31:0pCzR1vf2Ve6FJqThGyBuBw3DyFSInKN24h/S83JPeLt+Lj8Y7Z2EOKAWXfUKAbXRMRdsjkyPpfZA3D+gVmxXe8EYJfPn9t8qLISYngKMS8NsrLtrn1r0oGZ2yfYkIqtYlpUilFuPDu1dF6JT2/4XuTniNSTakKkK1ZTAgB4LgoIWcdj1fr4XYKoYStmy1jdEoeWkCsoU+XLfKHuXl+agaP6JMNG8qQoK8VIDrVZA1Y= X-MS-TrafficTypeDiagnostic: BN3PR07MB2515: X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2515; 20:YJAcnbNPglDtvGms4mL79A1alGKf+Yzu9rVfiYvS1dsmU/Bvtblp5Dv1Yh+zptaMg8sGtJsYfN7LLOkGdINF9u8QC/vwrmRv8WmU8w0UGwy8fgCx/fN2heSi/C6UI0sJcWpNXxgjucV3gKfVsqYjp0slJaOjYO4csUleNU0+J9oVc61hz+xLub9eyqNIMWdo7BFRUAZTcFfOiDBKQWNW6n6atjGxvD6BZQ76LtzmGRxZDi18VnhrILrc0cCBL3COVqDghOskZxGyUC9oIyV44ug3M6TA4uwSMuFH8wlcD9VrYUXc4hIJCTDbv79qjToLfnRwy6XNcZ6gF3oEygYwJKozQlL4DSQmPS7m/wdsC2cjq6Nyqhk/bUJBTYR+XB6P8JNYkXWf31C55q6VxPMZUfh8yMaTA1Ui6NQzcyIuEC7NIzbYqk2UcMtgkwvOfP9pnl4ehwiIHK6vywYoFrTZWuiCgTXe9DLAfwMVx0S1lHXduW6cGXnDaO5BL1tCqBGXJkBPvUdyDTjpU4YX9aUkniFE2E672hEFR43JqcGytcVFNzNWN/cc3N4e/KHhQLwUUqZRmmZOs4Ua7fkks9AJcsgS9Coj1nBZLIa2qIzYKgY= 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)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(100000703101)(100105400095)(6041248)(20161123558100)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR07MB2515; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR07MB2515; X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2515; 4:/IWCNPGIb2SyoNli9fKKl6KvfM6KdZrr9EwCA2vloz3b0+OGwOVzYDEJkKcbSeZCIEpWqDfREFE79rcyPwDpNhM08B24puKyoKZfG4yYJkBvqK03oBdpSLmO+a2Dide8e+lUOHJA1GgvbwIPjvo8h0vGtznVSRDPxMzA4A3KTSvw3xewbJBaRaFJVrBZ/KB4vNKBtddG5RGZax5k/3geobh8zJy1l4wJh8nqiH1/3g/SDggN8ThiU6H9rkh/bQk6YPwBicnEOqNfrR1l5eVsGhtD6LrLMDmTiHMJ14Tpil4KO+hlxyHA2+Q8bsI/QzW8jxyXPAZ0K6vJV+8fphuupN4Y6hQ1lYsKBEe1yXDztnD3NvdJ/nC9A8T+othmdztvue6tn3GIZX5w17R+FbEXug== X-Forefront-PRVS: 04270EF89C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(13464003)(24454002)(189002)(43544003)(199003)(377454003)(53376002)(478600001)(6246003)(107886003)(7736002)(6666003)(42882006)(53936002)(6496005)(229853002)(561944003)(7416002)(305945005)(42186005)(110136004)(25786009)(53546010)(189998001)(106356001)(2906002)(4326008)(105586002)(8656003)(47776003)(66066001)(76176999)(9686003)(101416001)(54356999)(50986999)(966005)(68736007)(23726003)(3846002)(6116002)(33656002)(83506001)(4001350100001)(97736004)(93886005)(33716001)(1076002)(2950100002)(72206003)(6916009)(5660300001)(81166006)(8676002)(54906002)(81156014)(6306002)(8936002)(55016002)(50466002)(5009440100003)(18370500001)(7756004)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR07MB2515; H:jerin; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR07MB2515; 23:g3GKdEFS74uQ/OODZzfukUNBMPIeiI6CD9kSR2uWw?= =?us-ascii?Q?B7S6IcBB6SGwtca5uo7wxuhEAcIainH5646WBLnOoLGPMtQQZEip7dTi222V?= =?us-ascii?Q?ADEMLOaS8mcv4eD+FegB2FAmjjd5ciQJk3palFuxo99EMXORqhJer5tB0HY5?= =?us-ascii?Q?cbG9Y5QErufnNelmGRr/mEedWuN2JxVchBYveg3bhAixGe1nXykBnIRrPpIo?= =?us-ascii?Q?jlC6d4hekn1mSyfmtVtlJnfscDdqnjMJeG4N+KCkFDhT0IFReIc7L+yrxnsq?= =?us-ascii?Q?seQkPQh96PxlgEb591PoHDtfoBlo7jjlYEoRNIBSuO+38wZLx7pefuAkixio?= =?us-ascii?Q?WMoGD9Rg57L1O/ULpl1JDkoG7n8ZWkB9OYAx2qnwOuYTsHO1eU9IE7x5Gd8C?= =?us-ascii?Q?eoufP6TnNZIRs2MxmjQh8G7rkKmY6/GbSn7m+LwtizXuvW1yhRlJhwIRSe7C?= =?us-ascii?Q?xFv3qhoAA5g8GJv+BwqQuHNegFzEhgc/DNNFX0lUc2hMmvmzJY7zLGxjJ2DM?= =?us-ascii?Q?nNpy+26ScLqDp3qko9G/5hC8lURpz+ddorsFMDVoYNQUxJxOPHDtkpviQ9wJ?= =?us-ascii?Q?8axiwVWpgBcVwhckLjYC4TQLbD09TX1KYG5codd07XE5NpKIQg+RPSHUr73R?= =?us-ascii?Q?oGUHW/dOHn/aRzjtEMD5iaURQLbTPu2LyYLoT/hdvQeM+y39nunqAWcXOxbB?= =?us-ascii?Q?uFWyEefXd13rVzO19A1tUuofFy7wRPRC0xIBpKXvPii2Y4ivAPx8KknRW8Cp?= =?us-ascii?Q?oBR2uDE9ebEqWexJ0oCm5TG3Sm459KLLaQjxqWr34Tn2eic7BwcXbmckIgd6?= =?us-ascii?Q?lDtAkOiOqiswGxwOfPHq1zZSTv6C9Pu8M6lYC6QKQ+WTzGsgsddJiDwxZ0rW?= =?us-ascii?Q?pEcL3SvmRl+vfG5VQRXGQnXP/d1c/3E4X7Mupt0QEyqn9AfUGO9CEvqXQRnF?= =?us-ascii?Q?ADKu9hzgTjpEDmfPcfhjw3nIDUfqOo6JGQapKJpvESXDmfpbh7tNFgMd01NE?= =?us-ascii?Q?rE4/Te7FGd0HJm+R0vG5znG1JiiFrLc6KF475GwiGCcMRvYT8lKu6tguCWQh?= =?us-ascii?Q?g2QsGpEm45hPq+E2DF6t3C7enCSsRKNPIDPS/xPXmO3KD9/22upS7kvvtkS7?= =?us-ascii?Q?yhR//uP+BY55PBc0qH+m4Fgle3PqGOiKtUSh1HsC5OIse5dA8l7poQ372h7J?= =?us-ascii?Q?b6MDFt62GnpuEmNUkqqrKAbV2O+iRD9ipBsYThDXNbrQMznZhL641jd0b/ty?= =?us-ascii?Q?2tJpiQvkGlEnz0Z9s6v+CTJtqEwF1mOBPcL+AOxch0wzwZZUiHfOJrgf0dqu?= =?us-ascii?Q?4xNdAKTAExakG1+/efZdHQW7fDlHwxtC6UP2yVh48j7N6oBnRzTSHUr4QDVV?= =?us-ascii?Q?IbgNedL30AnIHYIvcgEJemWjif0+Boaba51650Hnppev/1igLHXhUG26b6+j?= =?us-ascii?Q?/s5K9gLgy0E0IM0b3ECzTS9DqehDNbb7Uh+Hoh501nozLIUst4PkGFddXAXd?= =?us-ascii?Q?RSVVk3P8nEIIdrzqkCXlTdhe3rimayqqfk=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2515; 6:Led9qFJQaxx8Awm45+ewAXkZqIB/iOF04mC5UrWRhnRjIwz/kzPlJg4KCHm4kLuReUOzI+11NndvT04WMFh1CcoHC78zBQ7X5C+AqUuduX8Rrfy0Q6PuwyYyYRVyjdObNE/5gBX5NZ69m0JUaOy1E+GOGtlimL4wShVwWGOcblXgHfp4Ns8Ta7P2/8qrh1eAYDcWpbo52g7YP5dZ6nfnLuQPFQZCsxkKl5o2FAIM9nr1x4rw9wjJHo+j+BC06c3ZkP77GuVev0ik2MzMCjIQCH7HN50I+sQFkdp0W1KJxSXpZdqN1SOyu6hA6jmiH5akXUn2dGo6kGp1ATDKXZ7/nw==; 5:1DEiKIbEaQhPfFj6DLhNXt0GP/0sQPvQDt1wXDIlsefQQ6eIXZED14yiDjUEU31RHqfz9vlKvd/DBZX0dIKjPRTNq1Elf7x8injad/q6aGttzI1ZKoPmKTqzDKLlzXivLtWubpE63cc22NbgikxnWA==; 24:CEpZEhyi3XAsN186l2vMzfc+DdPX2EafpsEUtzClHcHZDYQ/m0oUtUhao+CoGT68cK5vLu59xlP4TWM9VU1FnyANG99ojli5GXHWHH3kg9Q=; 7:6swDXYcEveqGf/Z9T051jCqmF1Oe7gGMqEZ+XklZFLPTXSxMnn7Yh41ZicUFUIHIsw5dhA1PQ5+iGlM0kMPsStq63VvON+v6l3D0+4M98f2MZBWn3SyZhFfIs/ONivbiaUF2XFYkyRCibZ+W3cDXqWuyNLAZGdo9K9pLNYwtvgwsJxo2T/ZfIG7nfNpfiXilfmnemupPwRfUZzI7qT/v70bp33n8i2/4w122K9DKoSQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2017 18:10:42.6105 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR07MB2515 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: Mon, 11 Sep 2017 18:10:50 -0000 -----Original Message----- > Date: Fri, 8 Sep 2017 16:42:56 +0530 > From: Akhil Goyal > To: Jerin Jacob , Radu Nicolau > > CC: Thomas Monjalon , 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, pathreya@caviumnetworks.com, > andriy.berestovskyy@cavium.com, sunil.kulkarni@cavium.com, > balasubramanian.manoharan@cavium.com, suheil.chandran@cavium.com > Subject: Re: [RFC PATCH 0/1] IPSec Inline and look aside crypto offload > User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 > Thunderbird/52.3.0 > > Hi Jerin, Hi Akhil, > > 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. Yes. Nothing much happened on mailing list, All we saw a few comments from Thomas and which ended up as NACK. > > 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. OK. We will review it. > > 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. OK > > > 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. I thought, we need to keep the header in both cases otherwise the application may not able to check anti-replay if ESP header removed. > > > 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. Makes sense. This is the hard part to solve in inline HW IPSec implementation. I suggest to keep API experimental till we solve this hard problems which are tightly coupled with HW capabilities.