From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0074.outbound.protection.outlook.com [104.47.36.74]) by dpdk.org (Postfix) with ESMTP id 9524B378B for ; Mon, 20 Nov 2017 20:09:50 +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=DXB188gUW9JF+NMognICxydz7195S1yylZi6K2H3s/s=; b=CO7KbhJhPX4VFwAU85UbomyIBaAaoGOedhDOm3NbouXyRNFg7DmpXS1/NvinNUcPgfMHSaCBl2vsRpVbs6Ai+aQ74Z6/O+t1M4WOWHW+MhL27v99P7ASi0EQ76dOGdQeFLYNeP8gc6AcZHUaqBE15q1kRHNsuuBv7XgfizY/5+Y= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Anoob.Joseph@cavium.com; Received: from [192.168.0.103] (183.82.140.80) by SN4PR0701MB3646.namprd07.prod.outlook.com (2603:10b6:803:4d::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Mon, 20 Nov 2017 19:09:45 +0000 To: Radu Nicolau , Akhil Goyal , Declan Doherty , Sergio Gonzalez Monroy Cc: Narayana Prasad , Jerin Jacob , dev@dpdk.org References: <1511173905-22117-1-git-send-email-anoob.joseph@caviumnetworks.com> <1511173905-22117-2-git-send-email-anoob.joseph@caviumnetworks.com> <906693a1-f1d3-4986-6f53-619d120ef075@caviumnetworks.com> <003db6e1-e0a1-257d-230d-da6a3cf09ab1@intel.com> From: Anoob Joseph Message-ID: Date: Tue, 21 Nov 2017 00:39:32 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <003db6e1-e0a1-257d-230d-da6a3cf09ab1@intel.com> Content-Language: en-US X-Originating-IP: [183.82.140.80] X-ClientProxiedBy: SG2PR06CA0135.apcprd06.prod.outlook.com (2603:1096:1:1f::13) To SN4PR0701MB3646.namprd07.prod.outlook.com (2603:10b6:803:4d::12) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 31a6c82d-3fcf-4789-1878-08d5304a44c3 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:SN4PR0701MB3646; X-Microsoft-Exchange-Diagnostics: 1; SN4PR0701MB3646; 3:KsSoG0AKI3u5HBlnArKwviA4qt3PX2kYbAgo31mXmWbsRa3OF+KNvJ6LGKvSE+fq14Zdb/Gx3SuKSu4ijbvNCt+AlZyb/JVmU5Q4q+zdLtIrpYajeImUJk+8dz4u+alpMVgEdlLAkDDxhy9PLDQVLBD4FEcGdjvZHYfHeBmnhN+KDs5gLW88jQuiiMJiM57oHwTrCNCcrZ36Wwl1WFnmbmANsqmB4Ue63weC+Tz1QqSzoAbu+zhhQzzQ9AtWl295; 25:86RS4BNI9KPSFC+aX5ZkVJ1BUwfjb/A1s141I05xhhGzhavN8YuXge8jQWnJbqz6y7h61gwbHCyruwyseEODgmun1VnWlM+BnPUyt9ZRIsNGQHXfbvjKhRMNCvSTet7SvBZlJJDJgr9VhQtNwIY9W5JbP3G5ZUSXNmy7LouS7AFGTP52mgRj+V11o3+ukJ6D+4LIZgNwoo2X5kF+UCy7NonhLamip4rzVREiigY9tCxhh4YsbSXRTW/DUbfkIqYL2FUgZEm+nNQvH00tBrlBteA1AX6nggjWsDXyMEPk/ouqzDJxEdb6ZCoUI/4sP/uch0inBqCqYmrDbHv7yac8Vw==; 31:sZap9ZlDboGi3D2RjOAREQnCflP0ot4mEenj/3c6L37+KzS1NbBKNlKBszloCOi0b0ZPTMlm3+RcwFlu+T88e4o3klLIaTpjgdcgKCGRIWdQDLPaGZ2MldfbV56KvpgM2RbKBFCNRQ/5yT0li4ErHIq51EcTX21+MvBlRqDV1Gb4MSwR0eYKTexX4Y1K+kR/5B0sZt8m0EfCa0WFJr1jLpJHLMc72Kly10yLKnlKv1c= X-MS-TrafficTypeDiagnostic: SN4PR0701MB3646: X-Microsoft-Exchange-Diagnostics: 1; SN4PR0701MB3646; 20:DwDr1VsxE8ypWr9dyAUUBJAnx+UNXCh2ZklV+G/v1R3JXF0pZnnKayYooe5D1zAsmlikHeOyxDJq9SRf4qPaHrKYOS8WDUNMWhiofkp/iUXDPiyLcIsg44Z57s0BzXK11+grJ9Zv4LLFoTlDt65jSzIGlY4phAJak51doBaJJ1amBkOvAj8LZxNXRp0XapcBLZjZrAyXbXrySYqx+XeQ586SqDGzP5reaSJu3ul4IY8Uv75NdDI+l8HCZLr37cd0GfZP+ZabWmnVvXmTg+lUOQK+RBWEaBwB5u/P6Emt6UhK6Jc9My9Rf/vXEtvyvwU8DhlYhfC+/Rbze7Xt76/5UnhbVPT27NrICPkCp8BetFcccPOYxwCtP6171ZyYp1p2uCOKogEszS0bSbDRIIC050sFnUvWKAiV8my6FMUktgH5L6T03LdUFTNd6xCE4jFxN5oRHS5gdiZmXdxh8WN5e3f64d0AB51SSmd+lN2dYpbJKcGbqBfJWf+/21hxAeopS2Ovg8i0XLgw4Wdm/m0fHz3UhjJntGQCHtCu6q7SQXOKt50UjXULGUiEDOe2nQVSh+V1Ui6Ypr12bTXuoRjs4bylPSyXxDwvjMDE4O+vvBo= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231022)(100000703101)(100105400095)(93006095)(6041248)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN4PR0701MB3646; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN4PR0701MB3646; X-Microsoft-Exchange-Diagnostics: 1; SN4PR0701MB3646; 4:Y94y7x6Ae5/IWA/HssnE6fK0KvWWUWGqmEs7yIgMO4sMsK/vAB6Cv3kb/79WpGg3WAa/bY+TzKRMRFR12Rj5xBJVw3Ah5EUAyqYNGv6tj+tA/TzVq/TljBD/lcmQjXd6gWi3MQihWngYz6FWBDbDavjevkl2LLoO8fJpQuRpSzmqzYk0/FVWhUmX93j5VHVUuMZEVJJeq2jTlik3RVVa6qKgVN8ZAWNval17qNwrQWbEvIT+V4YPl1CYb76iKSgnj5h4YCIx8xPH0k/alHVg5CAeaLsiEuET5rkSLr9wQcuMCfWmb42nHJ0fMiMEAVR9vx7jw8sas84YtpCr1uDDb2P545/LDVs3NPTB/ScBDJU= X-Forefront-PRVS: 04976078F0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(376002)(346002)(199003)(189002)(24454002)(51914003)(377424004)(52164004)(189998001)(84326002)(25786009)(8656006)(5660300001)(83506002)(3260700006)(117156002)(65826007)(37036004)(54906003)(97736004)(36756003)(316002)(16526018)(53936002)(478600001)(53546010)(6666003)(93886005)(72206003)(3846002)(54896002)(42882006)(6246003)(31696002)(64126003)(2950100002)(4326008)(6116002)(68736007)(81156014)(8676002)(81166006)(8936002)(101416001)(77096006)(6486002)(236005)(33646002)(54356999)(106356001)(7736002)(105586002)(76176999)(50986999)(65956001)(65806001)(66066001)(229853002)(2906002)(58126008)(15650500001)(16576012)(16586007)(110136005)(31686004); DIR:OUT; SFP:1101; SCL:1; SRVR:SN4PR0701MB3646; H:[192.168.0.103]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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; SN4PR0701MB3646; 23:KfPOwqWZG5JpewqIjZj4kgkVp19SQCDy0WFpMsi?= =?us-ascii?Q?P8haP+c5gdJRsKQO9N6wgooHGgR7KFPmOg0jqNxsBaNvO1xSwuPpLvhnoT20?= =?us-ascii?Q?osuZZ6B35qxbbwPwkzWQH/OtdQxeH78dnXvtY9Pm/QBMAQI4L33HP18ZjxWI?= =?us-ascii?Q?C0q3RAGAl8sXRVPLAVc2wszBgpVWjfVB2Wne7xPPfQsf5stnLFk51Fheb6rF?= =?us-ascii?Q?jSMeWRDZstvd3Rhwc4v1LthdEBigfkSq+Ws0DBIjDfYxWOstrrWuWXz8ThNy?= =?us-ascii?Q?rw0BGui5bR9yxNZCsPFpR/sD2e5ePYo0ocNNg9s/hZFrUZQULPRpnDChWn7V?= =?us-ascii?Q?LlohRv2xiDBPX3VGNNkQJYkN6obV+O7PmABTX3aNbqc2TYNmPaMcc8iTGmIL?= =?us-ascii?Q?S1WeXJ+6JesdRnRsXGERCyYkHjGVxLMkrGLBAa+BOFtUn8H5A3VC6Sdc7Fwi?= =?us-ascii?Q?GnMIzQq066RBphd/ZrX015XlHPjvHHMWuCRM+g2s/vJpN4jDQduwL29oQD9Y?= =?us-ascii?Q?C2PAqYxhVhO9TUelD2LBuZqx+Kp/7TPNElRACv3pmSW2McIaKzwkSmo4yQpJ?= =?us-ascii?Q?UumCxyRdCeDxTSQW0brekhMdjX7fOuFfAecJNxUoKNGv8LHn1+AHatertKSy?= =?us-ascii?Q?qRZilAbC68lJ3Dri5WPTLrn+bVDpxLlcc4AUBgGkqZvt/5PA4us5iA2jfuxH?= =?us-ascii?Q?e+Z3wE+n73MoS+rj4tp7AfpxrBQwF6UsTwmIIfFIltzdTM7ORobHsCxP0meu?= =?us-ascii?Q?Q+1VpKtKQ6LuQu+jcLECSqsZwt8lGosYLLwLW12YznHZDWBUHvnDzF5QoNaE?= =?us-ascii?Q?C1xcDT0QCxsN08KsQn6XYQ3vqCTK0p2p3gWBniW6884xfYsgWSQ+F8eCk8OJ?= =?us-ascii?Q?9HV4uZaj1LQyUWP6MjMI199JUqum5Bkb0dqNpAe+upxldPUpmYAISomYTp6M?= =?us-ascii?Q?dtleP8vqLK+Ulf740iFhysqCGMYqDPJ0ir2SDuCCXYdNvvFdY8xIuRiFkjZk?= =?us-ascii?Q?spB3GIzUCgSWlgZHIdx6SvGypE//5rvH6sOkYCHRrjJOGxU8ol8pqYA7ebMh?= =?us-ascii?Q?u1RpnPmtOB8au1VLxZ58crlnrFu4p645h2VLlNj1EsPBYNaEhctw53bfPOzh?= =?us-ascii?Q?tPVzKYTUyxCU6o4DLZiIYlFLDHMqQBXoC8eaTwG4zULwIle46UYBFGYVthlo?= =?us-ascii?Q?ULcbNChjtqy5ZZZMYcISIQHiJwMxc3nCUByIjFykgKXvoUoR9VlJ6LIWxhpp?= =?us-ascii?Q?5985rGRpwgbrAaG9DfOQPZsTgfvaF9GG2P4a6YuLTLe+r9zblmqNLMHxBOis?= =?us-ascii?Q?fxLqmLfEP6dIAdFZXG35eAJ28+4DVkD1ultI/sZiAFAVkP1ryOrfBDoI5myH?= =?us-ascii?Q?n00xACXzcKf3pedUAqS47XwQDk+l3ont0H3AFO/8+M2vvOqvgHFOkX8H2iIn?= =?us-ascii?Q?AZxmvlhJVXZRxWBbcoguWYsOfFklYLdJ60R20q5rxjJxOVhBUGVcdGxwoJas?= =?us-ascii?Q?a6Ph9lTj41tLkgklbXkg0799MSL/Kdlu1+zY=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN4PR0701MB3646; 6:c3bqa3OdVguvG/1vEFYju4xU7vTZRh3snc2JIFSVqYOtUkMQqchYhP2uGrpAW+NWmUxKWSYNGgHpbv6qsRzCwAdm5ArFNxVpL5edsi2VPhauSvdW4myZy+ZCnOiqHW2FuPDpza0dZdxA8W7EEy9H2/s6+PRC+I7uWo2+wr+kdldCK8AWTYFUkVXg7ZJQnsO/DdMvsK0mO9okrVvzQ80u8kREJNdPS6N1Gn0sRs0rcLdS0SzAO+gGNjWMnc3OulW6WBpXnJcApotS/agDU7Efs4cPIWdgbHsmBqMYDkRVbYJXJASeqY4dkGXvi5v2YoByetpsYlPVsYoUZ5nje3lt09N1eLTxb8tZMyDpp0jf/ws=; 5:vIOq7I1JuBLfBdV4LBKrAym9IrX6RYfhyhUknWrL9xtn91+hFeucLlDCu/xSpuA7N3zlnN/e5s1pDor078XlB4qjwY7Pvf79/zNhi0lyv/GyVOeVr5vm0FJafM7mXid9j9fKBSmZbjZmPmybAGr5XsK/f8kqjEklgAuG2MC5XtU=; 24:YgHKPPCcs217W2EXJUBK8X8uFHzAx3cfrTAVyMSU3lJuGpqWz52PMtTa/oIp3FQE3GTlzh5XuubOiBdzCH+p2awOyoldcVg6jpnlBtV0WFc=; 7:z+0+pMTk1+ZtqgRI3ky8P/PCtyLyyw1pctp3LGNTQDiF4Mio5G+twbB6gc1dvGIA/xCXymR1ipRIKMZt6IAJnuTYsM+hKI0oYW9v46ss919GoPeU8unFsZZErq2aDZiMYBcGyt/kREg0p3yBnjUQ+uoRYNY167CAy2r80ufLSgUMzW6TUppzPq06g2aZ50h7WVCWwDzejH8zE+eP4JrYqWnD1yU+D298yHEbO14AFnLaH9/TEOCQ3WhcEfnS/fyU SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Nov 2017 19:09:45.9795 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 31a6c82d-3fcf-4789-1878-08d5304a44c3 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR0701MB3646 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH 1/2] lib/security: add support for saving app cookie 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, 20 Nov 2017 19:09:51 -0000 Hi See inline. On 20-11-2017 23:19, Radu Nicolau wrote: > Hi > > > On 11/20/2017 3:32 PM, Anoob wrote: >> Hi, >> >> Having something like "get_pkt_metadata" should be fine for inline >> protocol usage. But we will still need a "get cookie" call to get the >> cookie, as the application would need something it can interpret. > Why can't you have a get_pkt_metadata that returns the "cookie" - > which I would call it userdata or similar? What I'm trying to say is > that we should try to keep it as generic as possible. For example, I > wouldn't assume that the cookie is stored in pkt->udata64 in the > application. I agree to your suggestion. The only problem is in the asymmetry of how we would set the "cookie" (or userdata) and get it back. Right now we are passing this as a member in conf. Do you have any thoughts on that? For a more meaningful approach, we could pass this as another argument in create_session API. I was thinking of a scenario of supporting more items. So added it in the structure. Naming is open for suggestions. I'll use userdata instead. >> And, even though it seems both are symmetric operations(get & set pkt >> metadata), there are some minor differences in what they would do. >> Set metadata would be setting metadata(udata64 member) in mbuf, while >> get metadata is not exactly returning metadata. We use the actual >> metadata to get something else(security session in the proposed >> patch). That was the primary motive for adding "session_get" API. > What they do exactly is left to the PMD implementation. From the > user's perspective, it does not matter. > There is no requirement that set pkt metadata will set the udata64 > member. May be I misunderstood the terminology. "udata64" in mbuf was documented as |RTE_STD_C11 union { void *userdata; /**< Can be used for external metadata */ uint64_t udata64; /**< Allow 8-byte userdata on 32-bit */ };| I thought the metadata in set_pkt_metadata was coming from this. And we were setting this member itself in ixgbe driver. But yes, it makes sense not to expose it that way. The API can take mbuf pointer and then, the PMD could dictate how it had set the metadata in rx path. >> >> Thanks, >> Anoob >> >> On 11/20/2017 05:42 PM, Radu Nicolau wrote: >>> Hi, >>> >>> >>> Why not have something similar to rte_security_set_pkt_metadata, for >>> example: >>> >>> void * >>> rte_security_get_pkt_metadata(struct rte_security_ctx *instance, >>>                   struct rte_mbuf *mb); >>> >>> and keep internally in the PMD all the required references. The >>> returned value will be device-specific, so it's flexible enough to >>> include anything required (just as void *params is in the >>> set_pkt_metadata). >>> >>> I think it will make a cleaner and more consistent implementation. >>> >>> >>> Regards, >>> >>> Radu >>> >>> >>> >>> On 11/20/2017 10:31 AM, Anoob Joseph wrote: >>>> In case of inline protocol processed ingress traffic, the packet >>>> may not >>>> have enough information to determine the security parameters with >>>> which >>>> the packet was processed. In such cases, the application could >>>> register >>>> a cookie, which will be saved in the the security session. >>>> >>>> As the ingress packets are received in the application, it will have >>>> some metadata set in the mbuf. Application can pass this metadata to >>>> "rte_security_session_get" API to retrieve the security session. Once >>>> the security session is determined, another driver call with the >>>> security session will give the application the cookie it had >>>> registered. >>>> >>>> The cookie will be registered while creating the security session. >>>> Without the cookie, the selector check (SP-SA check) for the incoming >>>> IPsec traffic won't be possible in the application. >>>> >>>> Application can choose what it should register as the cookie. It can >>>> register SPI or a pointer to SA. >>>> >>>> Signed-off-by: Anoob Joseph >>>> --- >>>>   lib/librte_security/rte_security.c        | 26 >>>> +++++++++++++++++++++++ >>>>   lib/librte_security/rte_security.h        | 30 >>>> +++++++++++++++++++++++++++ >>>>   lib/librte_security/rte_security_driver.h | 34 >>>> +++++++++++++++++++++++++++++++ >>>>   3 files changed, 90 insertions(+) >>>> >> > I'll rework the patch to include your suggestions. I'll send a v2 after doing this. Thanks for the feedback, Anoob