From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0048.outbound.protection.outlook.com [104.47.36.48]) by dpdk.org (Postfix) with ESMTP id 5BBC8200 for ; Wed, 29 Nov 2017 06:43:12 +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=SoPND9oS3m682Oec0YmC2OzF3mmvSP+T3Rd9ulEpgI8=; b=lxlMqmU6U+vvglf5sMmNTAGWuj8XOcr8PVv55guUaqtL6sq6ocCb8zHUBr2fzYzoGWAFXcrKTeC1vm8KAyjqiWhKuJelaOhDo058MySHsF8i8uqegexmwjfmZX91yKxzganzhLXJ3ocWdcBJf9OdPW9vu1k0fmp4Ky3TE12vyZQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Anoob.Joseph@cavium.com; Received: from ajoseph.in.caveonetworks.com (14.140.2.178) by CY4PR0701MB3636.namprd07.prod.outlook.com (2603:10b6:910:93::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Wed, 29 Nov 2017 05:43:06 +0000 From: Anoob To: Akhil Goyal , Radu Nicolau , Declan Doherty , Sergio Gonzalez Monroy Cc: Jerin Jacob , Narayana Prasad , dev@dpdk.org References: <1511333716-11955-1-git-send-email-anoob.joseph@caviumnetworks.com> <1511435969-5887-1-git-send-email-anoob.joseph@caviumnetworks.com> <1511435969-5887-2-git-send-email-anoob.joseph@caviumnetworks.com> <414c3491-7a54-09b4-0cde-a21bffaeb1ab@intel.com> <94ae34d4-b34a-22a1-e787-e2dcdffc8575@nxp.com> <63e76b4d-3e6a-bd74-3ad8-72fcacef0fcb@nxp.com> Message-ID: <849074b1-b46a-08fe-c1ad-86f4e603900b@caviumnetworks.com> Date: Wed, 29 Nov 2017 11:13:00 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [14.140.2.178] X-ClientProxiedBy: CY4PR1101CA0003.namprd11.prod.outlook.com (2603:10b6:910:15::13) To CY4PR0701MB3636.namprd07.prod.outlook.com (2603:10b6:910:93::11) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6c9657c3-cf52-42e2-efd9-08d536ec1286 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(7168020)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603265); SRVR:CY4PR0701MB3636; X-Microsoft-Exchange-Diagnostics: 1; CY4PR0701MB3636; 3:Nbv5j1PUv03K10k4d316zZ3UgOPSjQOelPtBBzAFhOMnkddOwgRmFk2tdqeUcaqN49kR6tdARLtOg2SaZmWURUpz1RwNd5+AxYPgUsd2X5QySlHvKPvyapkDqeEZDo9OdyDrUdYXi5kox4ihlOpkBl1ozuBtIpGt1eymA0pZXNrbhz5bx13Mbj2UyrCvLLb7jBCryIDRBsx4BTpLAfs9WcaEcL4b1Oa0MGP603oHq+JCiSAtlTNiRIPnPo+1UEjz; 25:6qAUljgTAt3H4yMWn8sb4PgHqPML1uLdfHNPNQOJqwr8gGuZPLavLHlmW/iMbPcTzsaqiFw20NVGqEGCdoSG7QytVE2NbXkynmVE9JZ0RGlvNzeqXDJLEMjuVejdSvALVMsgYxOYf8JaKjfrT5QBdla+yx341G85XOsKUXU3RQwaLtqNuun0U0Nm+RHwv3KEXx5Yf4XupMvoYxx0PCHpPq15yhT+taxb4hhjzVg380ss/wHZ8xH7glFMakPsBOZd7MigSH4EHCAbs6mx0F+2McIENR2Z1de75uC2HIPfoRD/jpHohIkCEr7//6cCh3k5NItN0ui4LGLhCQ4gF2VqjQ==; 31:MNJNyOF4HdoxwKxkoFDLzSb5z4905BrnJCz6PYZmfDiBFofPx6+j8apMYquKD54N44rPRW3ABb6zG9qkeLzRsj0hIotPShaa+Pz5Mn/fZlp/89SJs4A5ospRRttScvaLl4TCli+EQuR7c29HvwSX1kq/D2uluD7Y6bHbOGvlRSHCHbeoRwgNWqAigkkifny6XoD/quom8FFz2jkAJy0c/m9K3UNoI846N8mPH5AntI8= X-MS-TrafficTypeDiagnostic: CY4PR0701MB3636: X-Microsoft-Exchange-Diagnostics: 1; CY4PR0701MB3636; 20:XSV8F+9ciy1A9Vc3NFek6dH+EcqhJdgfaOMtTVNWynEcutvPczH9kDa4i6k5hRWUd/ldcku6yG3lase9rNjlH5fxgTIlmgzRaU+/xKqlWjBp2VTktrgwHeedFD+7Pf0mOK+0hPoh01Ter7/GsaQ6HmHckQ5zwmERjQiPPSUykKzBkas2M/Js4/9OCjLlXDqo4fX6mbC+ngSHNwdiZqL8McWkqwARJ+GwBDLGAHcnMSPTMQWpU+8pXCorScFMxJE8jryUS2x4r8T6r4PALe31ISjW00tlhLtOYYm/axkGU90UY2BqMEr4ynuUS2aEXWk3s1yt69awbR5/gKUTlXc9Kog217goq4gUVS3bIbsAQMSsjz6dMmQ22qhyZQDnlrq2dRoAn13KwybD/NxcTM9PRLimFvKKe/c4ID735V07RJOmvRWVgCHlhmvr/EoGEdo3vfSQ2v9+3U6ARixi8CF1dFnSR1NIWp1wgaaugowdEiE8E5dLBHGwBhXkczNo2TLR6kgqTZ2B5BtrId6Fmv0gZKBa4VdL9rLJkdQB7CHCPO6a83NY6juVFPJoRQZWr2f+XLYX+uP0ZjXnEPKWTOF3mIHKZOC4StraBMkhmjoBS+E=; 4:LmFv0QtPbRiaef/ky7Bl1OVWvbqJx2fiTFUL+5wOQNI7vN4tUy9Fgj+NqK8uKCUhtDTu6Xo3D7YDrllXaMIUDcelkJEn8Y7x4M3UAZxsd4lUsTdITrK7pcejFjjXSD6P16GCrBgn2sXYDqyvGXzC5EWpzrvYgO08dA4MQSCwV0PhBZTsE2V0Nv960XScRGe/Oa+e8rQF4yKZVJl37S8HjmchNIo18yRlZ088GDc/eQ6z1Px3G8Yt/3lj2iY83Ato0SDKHE2g1Sx5AMl6aAlvuvX22egvTvLDkQC/EZfPa1kXFBRJDco3Ie6AYXLjHoTk X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3231022)(10201501046)(93006095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(6072148)(201708071742011); SRVR:CY4PR0701MB3636; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR0701MB3636; X-Forefront-PRVS: 05066DEDBB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(366004)(189002)(199003)(24454002)(81166006)(81156014)(7736002)(8676002)(229853002)(305945005)(8936002)(3846002)(6116002)(33646002)(2906002)(5009440100003)(53546010)(15650500001)(23676004)(2486003)(5660300001)(52146003)(31696002)(52116002)(6666003)(65826007)(97736004)(72206003)(2950100002)(42882006)(316002)(6506006)(58126008)(68736007)(93886005)(6486002)(16526018)(110136005)(54906003)(65806001)(66066001)(65956001)(47776003)(101416001)(50986999)(54356999)(76176999)(8656006)(67846002)(31686004)(4326008)(50466002)(478600001)(64126003)(6512007)(2870700001)(36756003)(25786009)(105586002)(106356001)(55236003)(189998001)(83506002)(6246003)(53936002)(110426004); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR0701MB3636; H:ajoseph.in.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?MTtDWTRQUjA3MDFNQjM2MzY7MjM6R0dEQVZaZ1E4UWlYYnpJTWMxS3VaT1Rl?= =?utf-8?B?ZUt4dnRQOWNTOEoxNXY2VHNtbEVWQWNVM0NXTEwzOE9TS3ZGVjFhdWJQYkE1?= =?utf-8?B?RWF5Q2JZdXdKVFJ0aXVDc1RRK1hna2dYRUF0ZVcwbEEycG0vVzlaWUJEdmI3?= =?utf-8?B?UTd4WUxQc3hScG1hM0F4N3d2RFpBanF5UkhDRzZXeHhSNHNrbi8zWnBrdUN0?= =?utf-8?B?S1EwUzVjaHM5a1RYVDJyQ0tqbHBaTnF3Z3NxOFBuMFB0Mk9TOFlpV29PcW5y?= =?utf-8?B?WTFGa1dlcHZXbUFmRXhtbG5rOEV2a3JNVHBTNTI3TU1MMFRmUmpCTTNzdUR1?= =?utf-8?B?ZUFMRnc3TVZiT1g3Ukw3enNpc1g4NzJXd290M0g5WVZ1OHVndDl5TDJ0REZt?= =?utf-8?B?YzBLSmNaZlFSYnZFNjZqOGZjZSs4bGlscDR4Y05zbk5JcllJWGs4cXYrcE5z?= =?utf-8?B?MWNkdklOTUpuRTErbG9ZWnFwaGkrMGNVK1RlYThFRHhTeHNGSEFFVi9UZWYz?= =?utf-8?B?WVFvaVMvWDRmZjQzZGNYeGVtdklXclRSVEx4UXBJTFBqNjVHZjgvdXBURlpu?= =?utf-8?B?VmdUYTBxdlNVYU4veENOZncvbGZ2ZkNOR0xHcy9DekllVGI4bFhlQTE2SGR5?= =?utf-8?B?YmEwRFJKTDgrNWhrb0NPTFUvVENsUmhLMWY0TUE5dkJKV3VIT01vZWx1S3JY?= =?utf-8?B?d1UzTlIxNkZVRzNxS21YbUJUVGpVUWZCNEk0U0NvYmtNUzY2Mzh0TGtUSFNn?= =?utf-8?B?VzRMMWlHY3JBblAwWnB4MWg4MGtJbVJtTEVSN0tkbUwxM1pJR2M2REdqcXJn?= =?utf-8?B?eUdZb0pnV0VCdUl5S0Y1NXpCSW1DaVl3WjhIMzFKK0ZUY1B5UE5TbldINzVF?= =?utf-8?B?R0V1M1hoTFcvYjVSRTZtcDRuRHpFbEo5VTN2MTZMSndFZW5jU1czTFR3ZGZR?= =?utf-8?B?NGxFTzNSRTQ1T0JHeVNFL2twNDB4ZWJOeDFXTjJBMVZzZjEzV1p4VzA5Zjls?= =?utf-8?B?eUJsN3Y2N0UrNzFOQUszZ2dDdUtSTEJWRUVGeno0aEMxUG1aZU5VTGI1bVVn?= =?utf-8?B?T0FJbU9qbWN3dDdadExMRkVuMjZZTkR3NSs0ZmlSNzNVTURhL1MzakZxa1Bp?= =?utf-8?B?UmFneG9wbUs4enhBdTJHdFFmL1R0b2dJcnJwNkhVUCtvVUVpQ3BaTmh5bXNa?= =?utf-8?B?VXlsNVIvU28rbWExU0gxNHBYeFFLNTBNWXZubGJzc0VpbUNVWm52VUpjcTkz?= =?utf-8?B?b3ROSk1WeDZadEtESThyYTFmRHY5NHBrNk1BdmlJT1R2aFBScmJDRFZZVFJo?= =?utf-8?B?QitiaWhGNmNVUDBxTXk4ZFFob1NSbWF5RFE4Vi9iMTd3OE5IbXY1T1ZlbW9K?= =?utf-8?B?UEpiUHpwT1Nab2VmK0VTQnRLaFJ6UzJGSWY3TEs2S0FJQllHT01DS0ZWSktm?= =?utf-8?B?ZldOVjRPWlp1aVp4Y1h3S3NCdkRBNDZHam16RVpZNnVCN2ZDNTg2QlZIWlRz?= =?utf-8?B?a2xzeGl6TFY2R0lyVWxGbEpmOWF6TnVrM1Vzei94WmpEV2U5N0NZdUJFaGVm?= =?utf-8?B?NzZHSktLd3lWb0toby9ndHRRM1ZxQnp0NjRPekVjT0h3L0RaOXNIUkc5MEJZ?= =?utf-8?B?cE1YL0FRdWdWS2xha3lESjhDblYwWnBOSGN1MktCQnlQaUphanpwYU1OZm1T?= =?utf-8?B?NDN5MTZOMU9iNDNLdHlxYjdUc256c1FvK1BoWkJuUmd2a253b3MxcG1xd2dP?= =?utf-8?B?eHVMUStXVVdQQU1ybVJKYWlMWUZPWFJFaVUwTUtzWXlIUzNZb1JBMzEyOWFP?= =?utf-8?B?eC9CZ25qQnVWa0lMRGRIUDhzcFRKaWJTMTFEbGJrMzkvOTAwTXd3K3ppMXhF?= =?utf-8?B?YjZFaCs1QmRhdnRqeFphZ0RVRlpEU3BLbTN1Si9tc0NMUWVDdjdwLzRRemVD?= =?utf-8?B?TytOcTBJQkdzZFhLTXJaWWtzRFc3aGt2c2hiM2djUTZUYW1KUHNjM1dzN2ky?= =?utf-8?B?d2Q4blhsalQ3MjR4U2hxb0xWQlM5ODFwOFNYa2xSUWRISU9TVXRGTnVwci9P?= =?utf-8?B?TU5NR2UrV2k5SDgxN3RUQTRmaW5sRm82bURJdXZMWUNLZVFWVWtERGhlUGR5?= =?utf-8?Q?ooHIEGkzkLOudw5IWj61vOjs4=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR0701MB3636; 6:te/Lwv9B7TYlIDtQZu9iZUjTLxmSOyUEusWC/p3wJW9k0AqJYVn/YvRQn2dJCB4sl+bKfiBAV43GMyw6ETJbxCNXKIP4QHDu07gt7OtfIuHJ1bAU0T6XKgr0kZJjm1Lnn5aovfHy2KBxedmqESVQOLWS0J4rgsZH72V/nOi8fs3QpLohc3/RoupnNUND1AUkpzSxtt81wWHATSWZZh9I4llE22lTyD07bDv/ZpTgmngW8oTASBQsuuQLmqcv4poOaTKCwoz6HOLuGjcXgkl0o8YOg0dF/dnSxtKC65W641F6udX4wUmsm8lmDSN5jQ/nrI9quKXN4ZZuHUoGLPA9NTcWdaZ1h7oRyd+ncmNYL0c=; 5:83zmSpzQ1pyfZVjppBG8KOaksbNB+Tk/GB5N0K7YkjNXkN3q1t58pTiPCm388Xg258qoEOqdZm56Ux6zgbdzkAafJ2Q3vNZs1WLHyIL9vMVi8knW5uP0/7r8NRHOCRiKi8ULxy8rKBZ6o/8b8Is88eDx7hhJ2dTEE2h8k8Qpz0A=; 24:xqvLC1Y5EJvFT4vNLze4iiDuGMnh4CrL6DktlDDS8F+kEjmmd8VDz+4IMOQgNHgqSsNNeJOE+yFXa3MNhCtExqu+OrBoKpVbf1MKXqYOIWo=; 7:nJp+tXQsGDtGt+CSYCv3jNmwnl6xivWoXWAyTK26A/IKtdkkdHPUROudmATa/uI0RR83hh1f7NvYsgKyiPUsaYe3W0/yyT3AY8toVassmj2pSx0HAXJYJvovnOONQSTEOSDKtG7E+qyB6umncfVcwJ/6/XbKutuJfFoweHCWD2dYRqy8oeORWmXMeEUEKWAKV3zVVHUgFx/T5WW1POlGyoOnpyfVxXfoECPoM9fNP1fVEmDDHAYLlzgE+eKZTRgf SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Nov 2017 05:43:06.6152 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6c9657c3-cf52-42e2-efd9-08d536ec1286 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0701MB3636 Subject: Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata 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: Wed, 29 Nov 2017 05:43:12 -0000 Hi Akhil, Radu, Is there any update on how we should approach this? Thanks, Anoob On 11/24/2017 05:52 PM, Anoob wrote: > Hi Akhil, Radu > > Please see inline. > > Thanks, > > Anoob > > > On 11/24/2017 05:04 PM, Akhil Goyal wrote: >> Hi Radu, >> On 11/24/2017 4:47 PM, Radu Nicolau wrote: >>> >>> >>> On 11/24/2017 10:55 AM, Akhil Goyal wrote: >>>> On 11/24/2017 3:09 PM, Radu Nicolau wrote: >>>>> Hi, >>>>> >>>>> Comment inline >>>>> >>>>> >>>>> On 11/24/2017 8:50 AM, Akhil Goyal wrote: >>>>>> Hi Anoob, Radu, >>>>>> On 11/23/2017 4:49 PM, 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, application could get >>>>>>> metadata >>>>>>> from the packet which could be used to identify the security >>>>>>> parameters >>>>>>> with which the packet was processed. >>>>>>> >>>>>>> Signed-off-by: Anoob Joseph >>>>>>> --- >>>>>>> v3: >>>>>>> * Replaced 64 bit metadata in conf with (void *)userdata >>>>>>> * The API(rte_security_get_pkt_metadata) would return void * >>>>>>> instead of >>>>>>>    uint64_t >>>>>>> >>>>>>> v2: >>>>>>> * Replaced get_session and get_cookie APIs with get_pkt_metadata >>>>>>> API >>>>>>> >>>>>>>   lib/librte_security/rte_security.c        | 13 +++++++++++++ >>>>>>>   lib/librte_security/rte_security.h        | 19 >>>>>>> +++++++++++++++++++ >>>>>>>   lib/librte_security/rte_security_driver.h | 16 ++++++++++++++++ >>>>>>>   3 files changed, 48 insertions(+) >>>>>>> >>>>>>> diff --git a/lib/librte_security/rte_security.c >>>>>>> b/lib/librte_security/rte_security.c >>>>>>> index 1227fca..a1d78b6 100644 >>>>>>> --- a/lib/librte_security/rte_security.c >>>>>>> +++ b/lib/librte_security/rte_security.c >>>>>>> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct >>>>>>> rte_security_ctx *instance, >>>>>>>                              sess, m, params); >>>>>>>   } >>>>>>>   +void * >>>>>>> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance, >>>>>>> +                  struct rte_mbuf *pkt) >>>>>> Can we rename pkt with m. Just to make it consistent with the set >>>>>> API. >>>>>>> +{ >>>>>>> +    void *md = NULL; >>>>>>> + >>>>>>> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, NULL); >>>>>>> +    if (instance->ops->get_pkt_metadata(instance->device, pkt, >>>>>>> &md)) >>>>>>> +        return NULL; >>>>>>> + >>>>>>> +    return md; >>>>>>> +} >>>>>> >>>>>> Pkt metadata should be set by user i.e. the application, and the >>>>>> driver need not be aware of the format and the values of the >>>>>> metadata. >>>>>> So setting the metadata in the driver and getting it back from >>>>>> the driver does not look a good idea. >>>>>> >>>>>> Is it possible, that the application define the metadata on its >>>>>> own and set it in the library itself without the call to the >>>>>> driver ops. > My first patch was along those lines. Can you take a look at that and > give your comments? > > If we add this metadata in rte_security_session, we can achieve the > above behavior without driver maintaining the metadata. But from the > packet, application will have to first get the security session. And > then application can get the metadata by calling "get metadata" with > rte_security_session as the argument. So we will need a "get_session" > API(which reaches the driver) and then do "get_app_metadata". >>>>> I'm not sure I understand here; even in our case (ixgbe) the >>>>> driver sets the metadata and it is aware of the format - that is >>>>> the whole idea. This is why we added the set_metadata API, to >>>>> allow the driver to inject extra information into the mbuf, >>>>> information that is driver specific and derived from the security >>>>> session, so it makes sense to also have a symmetric get_metadata. >>>>> Private data is the one that follows those rules, i.e. application >>>>> specific and driver transparent. >>>> >>>> As per my understanding of the user metadata, it should be in >>>> control of the application, and the application shall know the >>>> format of that. Setting in driver will disallow this. >>>> Please let me know if my understanding is incorrect. > Your understanding is correct. That' the requirement. >>>> >>>> If at all, some information is needed to be set on the basis of >>>> driver, then application can get that information from the driver >>>> and then set it in the packet metadata in its own way/format. >>> >>> The rte_security_set_pkt_metadata() doc defines the metadata as >>> "device-specific defined metadata" and also takes a device specific >>> params pointer, so the symmetric function is to be expected to work >>> in the same way, i.e. return device specific metadata associated >>> with the security session and instance and mbuf. How is this >>> metadata stored is not specified in the security API, so the PMD >>> implementation have the flexibility. > The requirement in this case isn't exactly parallel to > "set_pkt_metadata". May be we can drop making it symmetric? >>> >> >> Yes it was defined that way and I did not noticed this one at the >> time of it's implementation. >> Here, my point is that the application may be using mbuf udata for >> it's own functionality, it should not be modified in the driver. >> >> However, if we need to do this, then we may need to clarify in the >> documentation that for security, udata shall be set with the >> rte_security_set_pkt_metadata() and not otherwise. >> >> -Akhil >