Hi Radu,
On 01/29/2018 03:31 PM, Nicolau, Radu wrote:
-----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.
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
