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

[Anoob Joseph]

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 at caviumnetworks.com]
>>> Sent: Friday, January 26, 2018 2:38 PM
>>> To: Nicolau, Radu <radu.nicolau at intel.com>; Akhil Goyal
>>> <akhil.goyal at nxp.com>
>>> Cc: anoob.joseph at caviumnetworks.com; Doherty, Declan
>>> <declan.doherty at intel.com>; Gonzalez Monroy, Sergio
>>> <sergio.gonzalez.monroy at intel.com>; Jerin Jacob
>>> <jerin.jacob at caviumnetworks.com>; Narayana Prasad
>>> <narayanaprasad.athreya at caviumnetworks.com>; Nelio Laranjeiro
>>> <nelio.laranjeiro at 6wind.com>; dev at 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 at caviumnetworks.com]
>>>>> Sent: Thursday, January 25, 2018 5:13 PM
>>>>> To: Akhil Goyal <akhil.goyal at nxp.com>; Nicolau, Radu
>>>>> <radu.nicolau at intel.com>
>>>>> Cc: Doherty, Declan <declan.doherty at intel.com>; Gonzalez Monroy,
>>>>> Sergio <sergio.gonzalez.monroy at intel.com>;
>>>>> anoob.joseph at caviumnetworks.com; Jerin Jacob
>>>>> <jerin.jacob at caviumnetworks.com>; Narayana Prasad
>>>>> <narayanaprasad.athreya at caviumnetworks.com>; Nelio Laranjeiro
>>>>> <nelio.laranjeiro at 6wind.com>; dev at 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?

Anoob
>
> -Akhil