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

["Nicolau, Radu" <radu.nicolau@intel.com>]

> -----Original Message-----
> From: Anoob Joseph [mailto:anoob.joseph@caviumnetworks.com]
> Sent: Monday, January 29, 2018 8:04 AM
> To: Akhil Goyal <akhil.goyal@nxp.com>; Nicolau, Radu
> <radu.nicolau@intel.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 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?

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.