From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0060.outbound.protection.outlook.com [104.47.38.60]) by dpdk.org (Postfix) with ESMTP id 6CFE71B66C for ; Mon, 29 Jan 2018 12:45:05 +0100 (CET) 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=W1JWDYfjjhwFuNoeeeljEdRyWv049H7g+x/smteXYGo=; b=GvNd/iG659W9TEimYYWeyfzM7S/OqC5n0Y6VvvQUiyTUvtihxE0IcJxLBG0AtpmP/YEArFEawmyogROeEeRLhrnIoMnsT3Nw4vZHDgovxYh1HCb6hEMuSUQTZiuzid86B5Tj4uGB6dvHAfpoy3sfrzqDbao5av5zHEQLBOlqZAM= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Anoob.Joseph@cavium.com; Received: from hyd1ajoseph-dt.caveonetworks.com (115.113.156.2) by CO2PR0701MB1063.namprd07.prod.outlook.com (10.160.8.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Mon, 29 Jan 2018 11:44:58 +0000 Cc: anoob.joseph@caviumnetworks.com, "Doherty, Declan" , "Gonzalez Monroy, Sergio" , Jerin Jacob , Narayana Prasad , Nelio Laranjeiro , "dev@dpdk.org" To: Akhil Goyal , "Nicolau, Radu" References: <1516626668-9031-1-git-send-email-anoob.joseph@caviumnetworks.com> <4ab55855-0649-4d68-7b63-b75a6029dbb2@caviumnetworks.com> <763A2F19A5EFF34F8B7F1657C992EE297B31E1D5@IRSMSX104.ger.corp.intel.com> <763A2F19A5EFF34F8B7F1657C992EE297B3202FA@IRSMSX104.ger.corp.intel.com> <8c1b457a-d6ea-1a56-cd73-385108f8c538@nxp.com> <5a9fe008-03a6-a7df-6a8c-abab60b8ad27@nxp.com> From: Anoob Joseph Message-ID: <2bbc02da-11aa-0c9e-4566-53ef9cdeea72@caviumnetworks.com> Date: Mon, 29 Jan 2018 17:14:51 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <5a9fe008-03a6-a7df-6a8c-abab60b8ad27@nxp.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: SN4PR0401CA0007.namprd04.prod.outlook.com (10.171.32.17) To CO2PR0701MB1063.namprd07.prod.outlook.com (10.160.8.142) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0a412962-7e32-4d0e-1421-08d5670dbc00 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060)(7193020); SRVR:CO2PR0701MB1063; X-Microsoft-Exchange-Diagnostics: 1; CO2PR0701MB1063; 3:8kCDMWiJhX0PuOem1DCD86lJ9yoqM+kGhpV9nrWO7cFsGRtWf72X0jw/29jrRheYNExntfzqWP0iOz+ZVpm4YCTGrWMS3qLIJ+CWGjkN72i76xQLF/MY/3ZgzSS/UhbsWmm3CwAiVVoBZePlOFiXppt/Hi80J1cbAWtL3umJbk0XZzPu7ykVbahKUm2k+E2AwMkzMsWLpKkgxTvo89u3tNWCGB+6p5DBgQ8XNi90kR/BnYxbbyBEkOqdEmxhHJV7; 25:SP3XMd03lmq0G10HtYuwuU+0MJtC0+VGuHCRsuMhuiZiG7rnI8la389XUVhASOA5rINhHqBGyhX+W6oLBdMh9wy88srM4rmvr3rcLqNotD744KEObLsoou1H/CPhm4LOqcN0YytNleS5+xR5inytxu//qkh8Lc5mVThXYEGEa0kmdOcli23pdGIPm/+mPBXEDIjbXrTGnP5y1Fl/1nYZ+rSmRmsNKxLuJ95L76b5TNv7pysy+WxemyxM10I4F7SjOUR5zehGH6YTt0/R/PWKLb7zNzuL0HF/dOKNqhU/FnVscQ1UAu4RxYnkwC1WgOR8rUedxUlsp3B0HSeL4xT6eO5E5DlTwB2SIX1z+GLTHOI=; 31:Nkg3TnQa4U595RIYlzyPKXEIkE+w/fPfKp/YQI3P05cAv6KsrRUcz0Z+DBG2IeyfT5f7XposI6N+yigrvQva9j3sYYwBDKfBBXcBI3Eiv41+XsHoxdVtRQkLvGRawEk1e0Txv3c2l7Vo2rWi9qQYPdMd+l8yM7XFcQtVQ2keugmtzaZn9f447GNVJGPAVE9Er8pAY6chOQL0gyMhgoV9tGuMTHCjDcRlVTFnMU03ZzM= X-MS-TrafficTypeDiagnostic: CO2PR0701MB1063: X-Microsoft-Exchange-Diagnostics: 1; CO2PR0701MB1063; 20:GD/zfOXDL9cbyv+T4182Anl4HneujQFOLPGFcQ0WlvDPuBz8CxyxL2m031wzE4J6CkZ2xT4oOhtzTzDkoPGMkBJUQs8mkInxAfHJvFheMr2lrBcnVLfi+75d1F8HulJ98Q+G4ItRduUpAtCGlkcyUG1B/DwNtZ8LDanyx6Av4NfAjLHMdEDADWt8+ooFo0ClXJQLQZyYDjfyE3pfeQhusPVxaFEpusEs9245VCqvYkMmLlP7juTjagUM4O7KUmYVSN5Iffk49pcJAmdb68Tf3ry8k9Ri1THsdA4xJxbcTE3BKVWkCDqL5EPLYqR4mbgbv37qtJXN5hcNYz25od0aBPCPc4bOKb/Jh+tzICew4jkrxXk7Aic6j5KI6HakMpiyeaY7fcTQBmvWpR5kn/D2/gDgb4PHQjb+76DnbpH5ceCgUaSiUyYGNEj68RbJNn/Zr3mXtxbO5ogQ3q0Su5dZhW/SdMKeEsA5MPpiJ/xG8ZFSUTy3BrXdZZlge0q5nYqot1uw1xWooMfdLmF8XZY8aE4Iw0IbM02fVumOG91LxR03uZzJcC9Zy8juschlDd3oSToBzWOxG8SSF3YC4SNKDWx9OlpGdlrmDGkbE38m0oA= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(185117386973197)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(3231101)(944501161)(6041288)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:CO2PR0701MB1063; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0701MB1063; X-Microsoft-Exchange-Diagnostics: 1; CO2PR0701MB1063; 4:JUi9aDvM3TPEbXBw6K7XS7LxkILWhFK6Qlpy3/VtM2xi78skrW1eAnZHQeC0r7lKhv51N80EYEjeJzz+fpHSVkD8j9t7QGLie6GRZhAO2C9X9Uz5ywi/Q7wke/qIqilblraM2VyuCjfCG2DeG4EyYcLT7E4q7jzah0cXWvc3B/gaxnahTytTPcpC0gBOfH7/Vn/bTV/HYhQ/i1wS8bWjYVDzbAqSe2exPXkeFBKH3PwPfk1PCigl9HAutADEUyuob5C6Phe3wfIqEYhyirJ3Yhq2nEe4chq8Uziq5tzh1DC2EqOMZsWx+qkZsBZ+YrKI2adzgBBW7wMFR5X0XCS4pNR5KAcH0ZKJPDMsit8QA1h0O8e8KJNAuk0Ew9ayksAN X-Forefront-PRVS: 0567A15835 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(39850400004)(396003)(39380400002)(376002)(346002)(366004)(189003)(199004)(13464003)(58126008)(478600001)(65806001)(59450400001)(76176011)(316002)(50466002)(2950100002)(7736002)(110136005)(305945005)(54906003)(66066001)(83506002)(6666003)(72206003)(42882006)(16526019)(186003)(8656006)(65956001)(67846002)(69596002)(6506007)(6512007)(93886005)(47776003)(53936002)(36756003)(53416004)(386003)(68736007)(53546011)(25786009)(2486003)(23676004)(31696002)(3846002)(6116002)(8676002)(2906002)(26005)(55236004)(81156014)(81166006)(6486002)(230700001)(52146003)(105586002)(52116002)(65826007)(6246003)(4326008)(31686004)(97736004)(64126003)(561944003)(106356001)(229853002)(5660300001)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR0701MB1063; H:hyd1ajoseph-dt.caveonetworks.com; 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: =?utf-8?B?MTtDTzJQUjA3MDFNQjEwNjM7MjM6cDhkZTVEV1VGV0wrZDczdzQybm1LNGl1?= =?utf-8?B?MTFZSk91eXU4YzdBQjNGb1pkWVcyUTdHS0ZxT05aTTMrbjVJdktET0hrTVhN?= =?utf-8?B?MWhSYkRwUXo3MDlOSjlVY3RaQUdYZy9UZ0d5V0ljTmlHdUU5T0FwS0dwNnIx?= =?utf-8?B?aUZIM1lpayt6TExlNDNSZEI1Z0RKczJ6N1lzSWFXVStWb0s3YVdOdDNEN3JT?= =?utf-8?B?MU1JUURNR0s3K1dVaHp5WkpzdUZjMEcvRUFFSDl5Z0ZWU0Z5d3Fhclg5WHRN?= =?utf-8?B?ZGE0ZXNmT0dxb21CM2RkTWZuTkZXVWFTTzRBb1ZuZmMxS1FqaHBOY2F0L1ln?= =?utf-8?B?VEJNM0MxYnpWSVAzWHBHb1pvbXVpWDFINTZYN2o2ZEkrK0Z4NkZhbVJvYk1a?= =?utf-8?B?UWx6bStRTjBRK0NEb2pqcXRySHJvcGRzWXVWMTFUalpMUmlBSjdpZWd4NjBS?= =?utf-8?B?K3BxL2hCeGNjRG13ZEVOL2wyZWxIT1RYVXh2MXcwWllyNS9HTjdRWkZhSWkx?= =?utf-8?B?VWlyR2liVWo2WFMwd1crUG5EZjRwTDU4Y2dVUkpOcmxIakFxb1lPY1JvY081?= =?utf-8?B?aDY1NGNjSktmYldRSzVyTjRod1dOb3Zla0l6cjBpRUErQkJQd0dIdXRsT3A2?= =?utf-8?B?WGhSa28xeU5XUXBkbS9RZmhEbXNSanFpcjZPNlhMaWxVZDVEWnAzUHRrajF0?= =?utf-8?B?V2VtUk5Nd2ZZd0w4VEQ5YTRBOVc0UHA3VHFaUm5ReGNoRUdVMWJSRnFBaXRC?= =?utf-8?B?SG90V2FHUjl3eEJ4TkpERkFNeVhQWEtNazVDRWpSbFA0NXNialhPa0FpVER6?= =?utf-8?B?WGhtTHBDVUQySUJSVnh4YXZYeTdxUjB2Vlo2aUhxeEJTbWxqUzUyeDl0NVNZ?= =?utf-8?B?UkpNMTV3bjU3UEtsTTZmT21aNUU3SHppN3RUMEVEczBpY0FGTFV6SWIwMGlO?= =?utf-8?B?RVR0U1RYNGN2WG02MkNtYkxPNCt2SElMNjk4cml0MUtSQU9RMzNkOHJQUTZr?= =?utf-8?B?MGhBS2wwTnFwVjFxa2s1dnVKRG9YMFpkdElpeWhwa1A1SkQvTzlIOXlRZ1B5?= =?utf-8?B?S1VPUlcxMVQ1RUs3ZTlDWUZacUtvSCtHY2g0ZDVQMENQMFQzSWhvM0FWNjFs?= =?utf-8?B?cll2V01Fc1pUV0FuRDFvdWR3emtweEhsVWoySmZqNnZOK2o5WlRGejF5SmIy?= =?utf-8?B?RkVKS2paY0o4SjRVSkhHNjBwR05WYUhUa1VrT21LVW0zSERuaXJoMG5JOU4r?= =?utf-8?B?anA1anJrUzZ1akN6RncxeERDTUVaaWNiakl1YVRmTEFIZzkzVTVwMmFkSXV5?= =?utf-8?B?eUVyajVDZmx2V01TRm5YN2d5VmxtWStZd0R5MFpQRndjVEEyZVZJVkQrOWxs?= =?utf-8?B?VXIzWkJ1TGFMN3ZpWnYzTGZYMkFpVnV4bXBrNjBpbk55bi9IVnhqZXZ1TmJI?= =?utf-8?B?eVlXRU0xQkgrUUJpN1U4ODBHZXBDZ0JFZlBoZlpuRDExd2N2U2d6QmtvYnUw?= =?utf-8?B?MkJjWDIwWE43V2ZMVDlZVUNFTzMwOFkwb0s2Z1ZCbklzRjZsYWJHRHh0eUxT?= =?utf-8?B?V3ZTaWFtOXhiNEVjNDlpMmRGWTRGU0JWdkFhUDlHaUF1NU1yMU1wdG9jZnFT?= =?utf-8?B?aDlPOHdnWUxCTzRUdXMxQzBRd09oNTlRTmNPRlgwL2p1TnJYd0hOOGFVeVZJ?= =?utf-8?B?eHk0NkNnOG9vMDFvMTZIT1lCNWE0RFVuU1U5US9DWWgxbkl0MW9NbEJMc2R5?= =?utf-8?B?NDIxWWpVYTVXWjZxbnBTZlJkREM1ZWNCQ0dTYk8yaU0yMmFCRkhLYktuVEow?= =?utf-8?B?bWtkWVBVZWNCL2FwNHB4SWE4M2JWYXdBTUtMWUt6dU91L0ErS1hWT1duNVdu?= =?utf-8?B?WmJyL2d6WWpucXJ4ak94ZndnMzRlTkU5SGhWZVdXVkxmSVFZL1Uva1RTZ2pN?= =?utf-8?B?dmdSaFA1Zlk5QjBPMDNZTUlKN2ZDS2tvdUs5SlhmdHowZ3ZvRnZYaC9pVTJl?= =?utf-8?B?RWJybUxTd0p4bm51YmU1bWt6N1RZTlE0c2Z3NmNmbXRuVXBES3A2bHpPb3BY?= =?utf-8?B?SHRBSERSY3lhOFJtUllmN3ZTQ2VMTmVOZXlJTko2SDJGdmxycUtJTzF0bnls?= =?utf-8?Q?9Yr1iAmkSnmJBmOiIDB7vEwe0=3D?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR0701MB1063; 6:+q5lYxgHkkOceBOs3SmazkAGnl2SGuxZhW2E4/4PUMayNYMsiLHlQpQQnCdNj4RPfC/8zUskVTfsQgxQGfsk7fM+ypPeSxTIOPiP37mtcH4IdQJgl8IC2QrHptjixPI/4Gk3gZLn+UobdAN3YogO44fpN/30SriQLh2hzB8ObqiOTV9+BuQlCAMV/1keS+32mol+/LDn+/pv69HpT/x1baWgoxmxXGzVmok3PbxUoDhB7a4eSLP/aXghuBDLyED1phYE4g6Li09jEe1WiITklYrkFUVxLkmSO/xE5LaG4z71AD+nYJv5QAWO4M3O9C+QN+xIWtc6yk6pHydjdp9ibm+RkHcQQoc3CtHEUbZdQuw=; 5:WNNGLGTpHOjAUDLrcigMgU+68I6FFW23BAC1Iwt1nNCEsVvILHfjaYWR2O4uoshndJPMPuXcCt0OlZJdriS2tiQiCnrH/oOs9lyGEyKY3G9wsWX2OKp76JNIewTeW8MY325bNe4TdMOTRG+MO2vjDjTBWAZTzxsXoQyWt2+Rjzg=; 24:VV6l/6mK2eNxR3u4lknO2vyPQqiifssKFuWPYF7yWzBI4iJhIyujNzWzbwxXNcXD0TBNm5KFBHse1rEFXycC1DXeMrjAjYe/TbjyPv112eg=; 7:9J6CPCfzX3iLA411/Yqzyfr7JIU2nGJ4u7DvqF19fF9CNQOdIRf7QmPoWCUia+76DjD7nsdjyxwLjgiegFf4aVzi2wveWFuAJDcRzZ3tJzf4QM8azZDjQQ1IEuAdm5s21PP1SpFQLtiRMhKYRLvOj/7RRYvoKb09qAMxPBQewSiaP6BsH1rRgSihd+kfj0L/wX8hzveN+5PjyxvzqOfqDJ1IlDv1EWUPzcMGWubPZz6YVOBzvCE9d3VFsob1ESLC SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2018 11:44:58.8681 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0a412962-7e32-4d0e-1421-08d5670dbc00 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0701MB1063 Subject: Re: [dpdk-dev] [RFC 0/3] set protocol specific metadata using set_pkt_metadata API 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, 29 Jan 2018 11:45:05 -0000 Hi Akhil, On 01/29/2018 02:38 PM, Akhil Goyal wrote: > On 1/29/2018 1:33 PM, Anoob Joseph wrote: >> Hi Akhil, Radu, >> >> >> On 01/29/2018 01:02 PM, Akhil Goyal wrote: >>> On 1/26/2018 8:38 PM, Nicolau, Radu wrote: >>>> >>>> >>>>> -----Original Message----- >>>>> From: Anoob Joseph [mailto:anoob.joseph@caviumnetworks.com] >>>>> Sent: Friday, January 26, 2018 2:38 PM >>>>> To: Nicolau, Radu ; Akhil Goyal >>>>> >>>>> Cc: anoob.joseph@caviumnetworks.com; Doherty, Declan >>>>> ; Gonzalez Monroy, Sergio >>>>> ; Jerin Jacob >>>>> ; Narayana Prasad >>>>> ; Nelio Laranjeiro >>>>> ; dev@dpdk.org >>>>> Subject: Re: [RFC 0/3] set protocol specific metadata using >>>>> set_pkt_metadata >>>>> API >>>>> >>>>> Hi Radu, >>>>> >>>>> On 01/26/2018 04:52 PM, Nicolau, Radu wrote: >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Anoob Joseph [mailto:anoob.joseph@caviumnetworks.com] >>>>>>> Sent: Thursday, January 25, 2018 5:13 PM >>>>>>> To: Akhil Goyal ; Nicolau, Radu >>>>>>> >>>>>>> Cc: Doherty, Declan ; Gonzalez Monroy, >>>>>>> Sergio ; >>>>>>> anoob.joseph@caviumnetworks.com; Jerin Jacob >>>>>>> ; Narayana Prasad >>>>>>> ; Nelio Laranjeiro >>>>>>> ; dev@dpdk.org >>>>>>> Subject: Re: [RFC 0/3] set protocol specific metadata using >>>>>>> set_pkt_metadata API >>>>>>> >>>>>>> Hi Akhil, Radu, >>>>>>> >>>>>>> Could you review the patch and share your thoughts on the proposed >>>>>>> change? >>>>>>> >>>>>> Hi, >>>>>> >>>>>> I've had a quick look. From what I can see you can do everything >>>>>> you do in >>>>> this patch with the current API. For example you can store an >>>>> internal struct >>>>> pointer in the private section of the security context and you can >>>>> increment >>>>> the ESP SN with every tx or set metadata call. >>>>> With the current API, PMD could store the ESN with the security >>>>> session, but >>>>> there is no means for the application to read this. Application >>>>> should be >>>>> aware of the sequence number used per packet. This is required to >>>>> monitor >>>>> sequence number overflow.In the proposal, the sequence number >>>>> field is >>>>> IN-OUT. So application could either dictate the sequence number, >>>>> or read >>>>> the value from the PMD. >>>>> >>>>> Thanks, >>>>> Anoob >>>> >>>> My concern is that we are adding too much and too specific to the >>>> security API. >>>> Overflow situation can be monitored with a tx callback event or a >>>> crypto callback event, depending on the device type. >>>> >>> Agreed with Radu, this looks too specific information. >>> Instead, we can do overflow checking in the driver and add a macro >>> in rte_crypto_op_status for overflow. >> We could do the callback when sequence number over flow happens, and >> IPsec processing fails subsequently. But ideally, application should >> be able to detect that the sequence number is about to over flow and >> renegotiate the SA while the original SA is still valid. I agree that >> we would be better off by handling this in the driver. But >> application would need some sort of event which would say, "sequence >> number is about to overflow, renegotiate SA", before the current SA >> becomes invalid. >> >> Do we have any mechanism to register a callback (acting on mbuf), >> when a particular event occurs (without dropping the mbuf)? If yes, >> we could move to that approach. >> >> rte_crypto_op_status could be leveraged for lookaside_protocol, but >> can we do something similar for inline protocol? Thoughts? > > Even in case of inline protocol, what is the issue in doing that? > You can write a similar code in the driver(if hardware doesn't support > that) instead of application for handling the sequence number overflow > as well as anti-replay. Both of these errors are protocol specific and > for full protocol offload, application need not bother about this. > Application should be as clean as possible in case of protocol offload. When SA expires, IKE needs to be notified to initiate new SAs. So there has to be an event from PMD to application indicating SA expiry. This needs to happen independently for outbound and inbound SAs. Even with inline protocol, IKE is still handled by application. And, in inline_protocol, the protocol processing is done after the packet is submitted to eth_dev. Unlike crypto dev, there is no status of operation returned which could be leveraged to check about sequence number over flow. We need a way to know about overflow, when the packet is successfully processed and sent. Anoob