Re: [dpdk-dev] [RFC 0/3] set protocol specific metadata using set_pkt_metadata API

[Akhil Goyal <akhil.goyal@nxp.com>]

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 <radu.nicolau@intel.com>; Akhil Goyal
>>>> <akhil.goyal@nxp.com>
>>>> Cc: anoob.joseph@caviumnetworks.com; Doherty, Declan
>>>> <declan.doherty@intel.com>; Gonzalez Monroy, Sergio
>>>> <sergio.gonzalez.monroy@intel.com>; Jerin Jacob
>>>> <jerin.jacob@caviumnetworks.com>; Narayana Prasad
>>>> <narayanaprasad.athreya@caviumnetworks.com>; Nelio Laranjeiro
>>>> <nelio.laranjeiro@6wind.com>; 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 <akhil.goyal@nxp.com>; Nicolau, Radu
>>>>>> <radu.nicolau@intel.com>
>>>>>> Cc: Doherty, Declan <declan.doherty@intel.com>; Gonzalez Monroy,
>>>>>> Sergio <sergio.gonzalez.monroy@intel.com>;
>>>>>> anoob.joseph@caviumnetworks.com; Jerin Jacob
>>>>>> <jerin.jacob@caviumnetworks.com>; Narayana Prasad
>>>>>> <narayanaprasad.athreya@caviumnetworks.com>; Nelio Laranjeiro
>>>>>> <nelio.laranjeiro@6wind.com>; 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.

- Akhil