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

[Anoob Joseph]

Hi Radu,


On 01/29/2018 03:31 PM, Nicolau, Radu wrote:
>
>> -----Original Message-----
>> From: Anoob Joseph [mailto:anoob.joseph at caviumnetworks.com]
>> Sent: Monday, January 29, 2018 8:04 AM
>> To: Akhil Goyal <akhil.goyal at nxp.com>; Nicolau, Radu
>> <radu.nicolau at intel.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 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?
> You can look at rx/tx callbacks (http://dpdk.org/doc/api/examples_2rxtx_callbacks_2main_8c-example.html#a26) but probably events are more suitable: http://dpdk.org/doc/api/rte__ethdev_8h.html#ac0bef2920a6ade4041cab5103f4700d9 There is already a "RTE_ETH_EVENT_MACSEC MACsec offload related event" so you can add a security related event.
Rx/tx callbacks would be either for all packets or for packets which 
encountered error. Neither is our case. So rx/tx callbacks might not fit 
in our model.

I need to attempt the implementation with events to see if that will 
solve the issue. The implementation could be a bit complex as 
"eth_event" is mostly to control the state of ports, rather than acting 
on packets. In that case, PMD could return a security session in the 
callback argument, and the application would be required to find out the 
SA from the security session. I'll give this a shot and see if this can 
solve the problem.

Thanks,
Anoob