> -----Original Message----- > From: Anoob Joseph [mailto:anoob.jos...@caviumnetworks.com] > Sent: Monday, January 29, 2018 8:04 AM > To: Akhil Goyal <akhil.go...@nxp.com>; Nicolau, Radu > <radu.nico...@intel.com> > Cc: anoob.jos...@caviumnetworks.com; Doherty, Declan > <declan.dohe...@intel.com>; Gonzalez Monroy, Sergio > <sergio.gonzalez.mon...@intel.com>; Jerin Jacob > <jerin.ja...@caviumnetworks.com>; Narayana Prasad > <narayanaprasad.athr...@caviumnetworks.com>; Nelio Laranjeiro > <nelio.laranje...@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.jos...@caviumnetworks.com] > >>> Sent: Friday, January 26, 2018 2:38 PM > >>> To: Nicolau, Radu <radu.nico...@intel.com>; Akhil Goyal > >>> <akhil.go...@nxp.com> > >>> Cc: anoob.jos...@caviumnetworks.com; Doherty, Declan > >>> <declan.dohe...@intel.com>; Gonzalez Monroy, Sergio > >>> <sergio.gonzalez.mon...@intel.com>; Jerin Jacob > >>> <jerin.ja...@caviumnetworks.com>; Narayana Prasad > >>> <narayanaprasad.athr...@caviumnetworks.com>; Nelio Laranjeiro > >>> <nelio.laranje...@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.jos...@caviumnetworks.com] > >>>>> Sent: Thursday, January 25, 2018 5:13 PM > >>>>> To: Akhil Goyal <akhil.go...@nxp.com>; Nicolau, Radu > >>>>> <radu.nico...@intel.com> > >>>>> Cc: Doherty, Declan <declan.dohe...@intel.com>; Gonzalez Monroy, > >>>>> Sergio <sergio.gonzalez.mon...@intel.com>; > >>>>> anoob.jos...@caviumnetworks.com; Jerin Jacob > >>>>> <jerin.ja...@caviumnetworks.com>; Narayana Prasad > >>>>> <narayanaprasad.athr...@caviumnetworks.com>; Nelio Laranjeiro > >>>>> <nelio.laranje...@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.
