From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0048.outbound.protection.outlook.com [104.47.40.48]) by dpdk.org (Postfix) with ESMTP id 9AA77199A9 for ; Wed, 6 Dec 2017 08:30:47 +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=xXWvDi0d/BbA87JKLRIAvtoUBu7TdG8I7HDuuxPx/Cg=; b=EBAf0MTaa7F0w19qTIVeq0u0h8IVnLVu6SP4E/qCB1NaGYFvclcCPAVfthtdcTZTWPsg2vKM+ZnX5CckXDg8kSoP66clWrAIA8g6OF41tb40FxFJwVt4wJZPdJHs+FR6hF7KKqskPKYYp+flKqQUWIUgNRQ7OJ06NFZ3mJyKyIE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Anoob.Joseph@cavium.com; Received: from hyd1ajoseph-dt.caveonetworks.com (115.113.156.2) by MWHPR0701MB3641.namprd07.prod.outlook.com (2603:10b6:301:7d::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Wed, 6 Dec 2017 07:30:42 +0000 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> <45060b96-9b19-fe62-7653-5ad734188c93@intel.com> <7f193513-bfdb-81dc-48b4-ee844928745d@nxp.com> From: Anoob Message-ID: <9603b9ad-1aa2-a724-7dd7-4e8d2fb05f33@caviumnetworks.com> Date: Wed, 6 Dec 2017 13:00:37 +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: <7f193513-bfdb-81dc-48b4-ee844928745d@nxp.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [115.113.156.2] X-ClientProxiedBy: CY4PR13CA0033.namprd13.prod.outlook.com (2603:10b6:903:99::19) To MWHPR0701MB3641.namprd07.prod.outlook.com (2603:10b6:301:7d::34) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: cba81df4-3aa6-4305-be19-08d53c7b437e X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(7168020)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:MWHPR0701MB3641; X-Microsoft-Exchange-Diagnostics: 1; MWHPR0701MB3641; 3:S4o+4xzXc/4vaavdd+Pd5fRjp1lgKdeuTPA9EWbzapPBlaMvPdbQDSwBinVl7hYuvG3/KTfGwE2j5aschlgGS0yHaVx9Z4hrSBsWV2H6tcUylZAZ9oiOsnWle0iy4nwy2Da+3THbApGkXEPO+Bf/rAD5AFDN92z3vzQeJ8FFA3UUxYBiUtfDI/M0FXvvJMx7axAmFhIqdPraP/PgeldUXnNprsGWvbAV0h+lyavmAi260ADqloN6wTFbq0cEfNyu; 25:asy1UQmnDgpr6j+5yOJRbbeiX0AJH2wUl8dUw+RFQeDsN2spqv1BdQ4ApRak4Jm4+wea07z/EjlKTAAH/I1w/LG+Vnvj8UNFj+cVG0qaBH4yxZPreUOh95gJJEygcE6nNsSuxQ8FXhTUNRds2iWgqXQWGp2gbRnSLuJkqVLF73Ym6Xmh1Fujs7jnQUpjyzh2c5k3c9MWgquQVAEBymviSULhDvUKfdIWXm8tqzBO3M0/zu6xr1uQMpjktyCXLrTXFBl4uFnLUBptMejnzPlSC4pZ3Q6relqRRwFwUPcjNUqIfgkG4SEjgYUQjERkdxBFmye+QczoMaiFpXKBICkdZg==; 31:uGXuXDpluFfJCGbLc4Xhys47qdMq6wJPOjV5AmTWNippUAV/puh7q9JSLyd/pY5dRfsOADbhLNZizqh2zfJoP9E3LSO4K7YGEtE5Q4DYC76bpk6kBi/AhC1JuCgrg6W5bfCxQI3QIzLM7Oh0hp8tCMIbu3T0XaZpZ7kFaXb/jP/TE5F28QiyKzsQ1ttZQ1a2mW+Kup0z2KzzlaVczybTeoNSy0BF2510/aIAPaejKtc= X-MS-TrafficTypeDiagnostic: MWHPR0701MB3641: X-Microsoft-Exchange-Diagnostics: 1; MWHPR0701MB3641; 20:Wca98UhUGeEveCRQryFVNk5fn7OIkEPNopAvl8JX4LbN+wwt4EN2UpX4MwBZGxfvgN0PVN6VcJNtJJ9PxyO+xbq+KE3fLblkPfVc0S+TEXR862pA4qPc+KpH2y0dAwClimGZDiwK3Cp+OfuiAMU9HRelqjGg3ROs3fzErn7FqQv+ADcnofbAtfyXjKXYhhWZNt+OZxyxQ8LDoNVsk1f7JqSb0WoNeafi7EiGx3h7EPskXyn00gGx4tj6ztW5tKmx5GOhybuqIqRHYnSe/2l45o9KXUYEuPUvlXPmFbI8sHVEXDS/I0yUpaq3jDR9tJmoyrbEjshPHDl70peZ0PIDJJ4TOcQuPXdiWB2JheIcUyCduSvkJeKoFLuopaK0DejbVpcuq54B+52Uug9Ty2rPo7v17j8NXvl7I61GKz5UBNOk3csGEuyb33anSz0/gDN3kvdADgYXEJ0aMVPc7FO8Nyl9pVRcjpJf+rewpl/CAXRHlBPa25PRFNHkWtoVMijc7YBpzNZrPLaQ714hn0TyA7WqDFbl/agRCgrgIF+strKymNHohK2N3P4u2t/ghhzQ71jLjHzpOIsipLFBfkIaCgCMxUM5V4qxyA6fNqVe+Mg=; 4:SSiMpEGrj0FJGJhc332iwQ+15MyR2SFmb66c+dg1QgkhI0/v8waedE8NDTHzS9sX3+Uv7ftMvoIF5F5e0xojBv0GkzYhCnWANnpyJzZGgiRVX4nmwZEnLj1v/5DkmCKDmrWDGLTW52Bi2zPjDqf+PXYSpbKtWp3Q9INHHhuZ0zXTFuiXjFmnObDqze2jzeHQcAdU4ae5SORkjYLW+Z2y8WI3NRZxsibVjfhKGIbffEKEy2BLPXcCuh8O2TYLaQRUnRe7Tzis+ivfYZCn1Fy0tapbLgL7H7OU9ayN8CUtLjcja5IQ1bEjQVuh/gj0KWgK X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(3231022)(3002001)(93006095)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123560025)(20161123562025)(6072148)(201708071742011); SRVR:MWHPR0701MB3641; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR0701MB3641; X-Forefront-PRVS: 05134F8B4F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(376002)(366004)(346002)(24454002)(199004)(189003)(36756003)(33646002)(4326008)(97736004)(229853002)(105586002)(106356001)(50466002)(5660300001)(72206003)(53546010)(101416001)(6116002)(3846002)(93886005)(68736007)(31696002)(478600001)(65826007)(42882006)(8936002)(2950100002)(6666003)(83506002)(6506006)(66066001)(6486002)(2870700001)(316002)(6512007)(31686004)(16526018)(52116002)(52146003)(67846002)(2486003)(23676004)(8656006)(2906002)(53416004)(53936002)(54906003)(58126008)(305945005)(7736002)(110136005)(64126003)(55236003)(81156014)(81166006)(65956001)(69596002)(47776003)(15650500001)(25786009)(65806001)(6246003)(8676002)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR0701MB3641; H:hyd1ajoseph-dt.caveonetworks.com; 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: =?utf-8?B?MTtNV0hQUjA3MDFNQjM2NDE7MjM6RFZnSVVyQXlGcjZibHBkbXB5cGc5aUQw?= =?utf-8?B?dWphQ1hLV0NoS0lrWDRSOHM4RDd6UE1XVDVNbjQxdkxvbi9NQUl0cUxDUG8y?= =?utf-8?B?eXNnaCtkV3ZwazlPSWdqZFZCd1ppM3pIalY4dG9TU0VpTUJCNFUxVWtqM29P?= =?utf-8?B?TSt1dk5MOTBiRlNyM2QxRFAvV08xU3FLdGtPWWs3Rmw5YWtsVjZTa1ZMeHRx?= =?utf-8?B?VGpKckd6dU1zNnNnNDk1NVk1MVFPR0xQZkhaYWRrQkZkTnRYMFlOdGRFdlZX?= =?utf-8?B?Qm13ZDFJa1ZOMHRxMzhiNHU0bWp4YzlidFJsajlZck1saVFPT1o4MnpwcjZB?= =?utf-8?B?NFNlditiaU9hZXVnblNUMURKMmRXS1hXVVpqb3dJVEs2RUVtUUR1TWtxQUpz?= =?utf-8?B?Rm0rVEdaMDRJV3hRNVAxNWo4T1MyMXVBODk5WGNNRGtrQ3BPeWpEZFp3Slg3?= =?utf-8?B?WFV3ODlWcS9JN2hvMzh3RXRQUGI4bHo0N3FxTzE5R3ZXVXluTUN6bHVYMk9Y?= =?utf-8?B?dXNuTk1JaEdmSUZWY1NMUkhoVWdFTUFoUG82S0toalZYNmhLNkc4Uys4Nzdv?= =?utf-8?B?aTh5SHNSRkd0ZTdUMmtyYW93QUhhcXRmdWxsRE1jWkRkWGN1Z2hrTkJXUGh3?= =?utf-8?B?Z0NwaUtSazhUWjErWXJOSHdXSHVvaWNveUdYRUpFU3hJZ1FZM3c0SW92cEVv?= =?utf-8?B?VFVnc3lGL3hDTFRDQVoxN0lEL3lLTm5iYVBOVHRaU3p4N1F3c2dpYUZDRWtF?= =?utf-8?B?bUliaGlZaytsOVlPVHpaRXNWb2Z1a1FmMXJHQ3hwSGh2d1hVRXFxU2lMMGRU?= =?utf-8?B?QUkranNXVkxZcEs0TkRhR3lsbE5ZZ0YxWmI2TnlhRi9OR1FLTzJ1S2dCUWFI?= =?utf-8?B?LzlQbFFkOFdYVXc1aTNGSzlJak9STHJCUXYwdmtSRzlsdXFhRE9YYWNIcHRR?= =?utf-8?B?a3VzRVFmQStKT3BkTUYwM01EUHdrUXFDQy9CRDdhdUVvZUdtQm9qZUNPd3NN?= =?utf-8?B?NFdoZ3hHMStqeHhSMjdwV25CYkx6MUdpNkV1ck4xbjFaYU1adW0zOElxQ1Y4?= =?utf-8?B?UXdyK3JyNkw4Nis1OE11SmhqeUVXTU4rbEFKNGNQSDdRWmVEOVJzTUZkRmZr?= =?utf-8?B?cThEM1hCY0QwOVFIU0M2RFU0NzlyOXorSjljQUY0S3RuQUtvWDZFOUNjNEcr?= =?utf-8?B?RCtSNVBaNFFxNzZycG9sTU00UDhNYTZTZHdnK1JwSllVREFGR0I3TXlrOFVt?= =?utf-8?B?d3Y3OU9ER3NVclN1c2VDdjlRTGZld1FhSGgrQVFVLzBZa2szc3lQcjNSbVZr?= =?utf-8?B?MjJJSmRzdXpRTWJXQmxnU2NTak5qNUNrMzBESktxN1VlQlNmRXJaWDFVZkFt?= =?utf-8?B?dWp4UFBPNmhMUmpIQ3hFVDAyZ1JienZsVTFtcGlJdlg4bU9BbUFiSDBFVzY2?= =?utf-8?B?Z01Wd0pSUWxSSkZjYkUwVW9tNDB1ZitYb3NmZURBRmpSL1duUldtcys2RG43?= =?utf-8?B?RDgxamdBQ214b25SNkJEaWxoSzE4SEZKeEloaEtjQldMdStaUm53ZGZ0OUJE?= =?utf-8?B?S1BuTGVma3VKc3ZicnM0RnF1NzQ2ZzdUbFArT1hObjJyRWJHVXEvK3Jta1NW?= =?utf-8?B?SjhwRVBoM0d6TGt6bENwQklLVXJicjdjRzFrVU5MNVZwaEVhY3J6LzhtZkhz?= =?utf-8?B?MU9oNCs4R25EMDNIWElLOXJCbUt3TzcrZnVvRE5kRTBtdXlQLzlraG9aY3pO?= =?utf-8?B?L2d6MENSTXA0U3NPb0hlSkd2aHcrdUtpcUhhR2tNckt4bDk0aEFlMEpFWUZu?= =?utf-8?B?c2JNS3V1aTZxRXpybkkwS2xubEVVWnFNald5VjhlbmVHQkRlZ2ZwZGlwS0VC?= =?utf-8?B?c2NSeU1qdnlYVGh0K3V3M29Bd2dzb2E0K1lWOTl6NkVLSTYwc3IzRGQzdFd4?= =?utf-8?B?c0d5akUzbTRreHg4bUx5L0FRUWpIL25pUjhvOHZnMEFzLzVhbS9VOCtSU1A1?= =?utf-8?B?NkZtSXpqTnVjTWdOVkZOS1kyaThHN25pcVlTSkx3PT0=?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR0701MB3641; 6:Aj/5BmYpVHoGOhXjGhhZBdqmrCyx3bbK49TF4IT44fZgCuibJGUJEWHaOr+JiHrXpr+tnaeI+4bsR71wREnbgcZ3MLRbr+hzff1RwI2nY7szJYUxmJMZ14hmGRIKE+YVMnf4tlxSgnKsZtR/WPHJVi/Scr5jLmR9rEiigHnxT+6bg1bLBuWNTPzSmTVeESmfrBzRGvVnTrK7I00If4sB8Ci8pRwBidV1vd4YofcgobW0aXFUpySmh88qTIGAjpT04STbEOUA1emL7vqrPM3Orm6qXz+8p9TwOk75aNkK0F5TIKskwLT3EshaXjzaGtascep9wYq4i2cD4JrtDF7soEi0HP+hoRVYeQFaHn6HhKQ=; 5:V7AAip2ObSSolRaRTA4nwEfXxPBJzhU03rjj0zeSTvEakU8a3HSnKofcmD4iHbMrezOODd18+QfHLqjV/qpXl1ZQJS8ttZtZeqNL/UzRVZJuw63ZxRyUp0ZqBk52+l+iUmgAzKpTrn2nuDDSxybUBanNYXIFCbM2nDjxwkl80Xc=; 24:VQ6iU0E9WvxtqyTr5C61aulNs5UN35ZMtobtO8gZyiVq56DqrxL+dzeAYWDDzxwvjOuaLJ7pbWeQSj/1q7+oxWnl27CtRyl4NXMqkEgOIGs=; 7:Sr0fjlEtenVt+LyE0DjR9jsNTf7DoARv3ipciJ1TRz+uC5cndTkXBbo/D7beKBMDapi6ksuryvvq4kWNCm99QdpRpr2VuvBmReoEGwA50OXxVAxH4OmxzNUMP7a9DtLN85t139sodB9/gSnvJAttu1VHh3jaG+bjoPrXt5KdXiWjuo8Elhh4QlwfrVrHrZ+/MlgPrL64gX2vw/HIUdClxmmmwzwSjFfDBvYvjfIOLBymoN7qFy0JdagZbGcVd6as SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Dec 2017 07:30:42.9597 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cba81df4-3aa6-4305-be19-08d53c7b437e X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR0701MB3641 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, 06 Dec 2017 07:30:48 -0000 Hi Akhil, Radu, Please see inline. Thanks, Anoob On 11/24/2017 05:33 PM, Akhil Goyal wrote: > On 11/24/2017 5:29 PM, Radu Nicolau wrote: >> >> >> On 11/24/2017 11:34 AM, 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. >>>>>> 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. >>>>> >>>>> 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. Is rte_security_get_pkt_metadata() expected to return a "device specific" pointer? If that's the case, we would need another call (something like, rte_security_get_userdata()) to get back the userdata, right? Or is it fine, if the application assumes it will get userdata (the one passed in conf while creating security session) with rte_security_get_pkt_metadata()? >>>> >>> >>> 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. >> Indeed, we should update the doc stating that the set_metadata may >> change the mbuf userdata field so the application should use only >> private data if needed. > > Agreed, but it is dependent on which driver/mode(inline or lookaside), > it will be used. > Lookaside may not need this API as of now. Other implementations may > also don't require. So this shall be documented that way. > > -Akhil >