[dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata

[Radu Nicolau]

Hi,


On 12/6/2017 7:30 AM, Anoob wrote:
> 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 <anoob.joseph at caviumnetworks.com>
>>>>>>>>> ---
>>>>>>>>> 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, this will be my assumption, a "device specific" pointer (similar to 
the "void *params" parameter of the rte_security_set_pkt_metadata 
function), which will contain an arbitrary defined structure that will 
be decoded by calling a PMD defined function.
But I think Akhil has a different view on this.
>>>>>
>>>>
>>>> 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
>>
>