On 1/29/2018 1:33 PM, Anoob Joseph wrote:
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?
Even in case of inline protocol, what is the issue in doing that?
You can write a similar code in the driver(if hardware doesn't support
that) instead of application for handling the sequence number overflow
as well as anti-replay. Both of these errors are protocol specific and
for full protocol offload, application need not bother about this.
Application should be as clean as possible in case of protocol offload.
- Akhil
