DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: Akhil Goyal <akhil.goyal@nxp.com>
Cc: Radu Nicolau <radu.nicolau@intel.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	dev@dpdk.org, borisp@mellanox.com, declan.doherty@intel.com,
	aviadye@mellanox.com, sandeep.malik@nxp.com,
	hemant.agrawal@nxp.com, pablo.de.lara.guarch@intel.com,
	pathreya@caviumnetworks.com, andriy.berestovskyy@cavium.com,
	sunil.kulkarni@cavium.com, balasubramanian.manoharan@cavium.com,
	suheil.chandran@cavium.com
Subject: Re: [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload
Date: Mon, 11 Sep 2017 23:40:25 +0530	[thread overview]
Message-ID: <20170911181024.GC26002@jerin> (raw)
In-Reply-To: <2ff5080e-2806-84ed-4e61-c982f854ab94@nxp.com>

-----Original Message-----
> Date: Fri, 8 Sep 2017 16:42:56 +0530
> From: Akhil Goyal <akhil.goyal@nxp.com>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, Radu Nicolau
>  <radu.nicolau@intel.com>
> CC: Thomas Monjalon <thomas@monjalon.net>, dev@dpdk.org,
>  borisp@mellanox.com, declan.doherty@intel.com, aviadye@mellanox.com,
>  sandeep.malik@nxp.com, hemant.agrawal@nxp.com,
>  pablo.de.lara.guarch@intel.com, pathreya@caviumnetworks.com,
>  andriy.berestovskyy@cavium.com, sunil.kulkarni@cavium.com,
>  balasubramanian.manoharan@cavium.com, suheil.chandran@cavium.com
> Subject: Re: [RFC PATCH 0/1] IPSec Inline and look aside crypto offload
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
>  Thunderbird/52.3.0
> 
> Hi  Jerin,

Hi Akhil,

> 
> On 9/6/2017 9:23 PM, Jerin Jacob wrote:
> > -----Original Message-----
> > > Date: Thu, 31 Aug 2017 15:09:45 +0100
> > > From: Radu Nicolau <radu.nicolau@intel.com>
> > > To: Thomas Monjalon <thomas@monjalon.net>, Akhil Goyal <akhil.goyal@nxp.com>
> > > CC: dev@dpdk.org, borisp@mellanox.com, declan.doherty@intel.com,
> > >   aviadye@mellanox.com, sandeep.malik@nxp.com, hemant.agrawal@nxp.com,
> > >   pablo.de.lara.guarch@intel.com
> > > Subject: Re: [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto
> > >   offload
> > > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
> > >   Thunderbird/52.1.0
> > > 
> > > 
> > > On 8/31/2017 2:14 PM, Thomas Monjalon wrote:
> > > > 31/08/2017 12:52, Akhil Goyal:
> > > > > On 8/31/2017 3:36 PM, Thomas Monjalon wrote:
> > > > > > 31/08/2017 11:37, Akhil Goyal:
> > > > > > > On 8/29/2017 8:19 PM, Thomas Monjalon wrote:
> > > > > > > > 25/07/2017 13:21, Akhil Goyal:
> > > > > > > 2. Ipsec inline(RTE_SECURITY_SESS_ETH_INLINE_CRYPTO) - This is when the
> > > > > > > crypto operations are performed by ethernet device instead of crypto
> > > > > > > device. This is also without protocol knowledge inside the ethernet device
> > > > > > If the ethernet device can act as a crypto device, this function
> > > > > > should be offered via the cryptodev interface.
> > > > > yes this could be thought of but the intent was to keep cryptodev and
> > > > > ethdev separate, as this would create confusion and will become
> > > > > difficult to manage.
> > > > I think the reverse: it is confusing to do crypto operations through
> > > > ethdev interface.
> > > > If a device can do "standalone crypto" and networking, it should appear as
> > > > 2 different ports in my opinion.
> > > > 
> > > > > > How is it different from mode RTE_SECURITY_SESS_NONE?
> > > > > In RTE_SECURITY_SESS_NONE - crypto device is used for crypto operations.
> > > > > In RTE_SECURITY_SESS_ETH_INLINE_CRYPTO - ethernet device is used for
> > > > > crypto operations.
> > > > > For details of the data path of this mode, refer to the covernote of RFC
> > > > > patch from Boris.
> > > > > http://dpdk.org/ml/archives/dev/2017-July/070793.html
> > > > > 
> > > > > For implementation of this mode, see patches from Radu,
> > > > > http://dpdk.org/ml/archives/dev/2017-August/073587.html
> > > > Boris RFC uses rte_flow.
> > > > Radu implementation does not use rte_flow.
> > > > So I still don't understand the big picture.
> > > > Boris asked the question and had no answer.
> > > I'll answer here: it was an omission from my side; v2 of the will include
> > > rte_flow usage, derived from Boris RFC.
> > 
> > 
> > Cavium would like to contribute to the definition of this specification
> > as our HW supports the IPSec offload.
> > 
> > I was trying to review the latest patch. But it looks like there are
> > multiple versions of the header file floating around. like,
> > 
> > http://dpdk.org/ml/archives/dev/2017-August/073587.html
> > http://dpdk.org/ml/archives/dev/2017-August/073738.html
> > 
> > Can some one tell which one is latest one to review?
> > 
> > Previously for rte_flow, rte_eventdev specification, etc we had some
> > header file sign off before jumping to the RFC implementation. IMO, That
> > model was useful where all the vendors could make inline comments on the
> > proposal instead of maintaining in the draft repo.  So it possible for
> > sending the latest revision of the header file patch on the mailing list
> > for the inline comments.
> > 
> 
> The RFC remained for some time, there were not many comments. so we all
> agreed moved to implementation. That is the point we requested for the repo.

Yes. Nothing much happened on mailing list, All we saw a few comments
from Thomas and which ended up as NACK.

> 
> The Cavium comments came bit late.
> 
> Currently I have just consolidated the patches in the draft repo and I am
> going rebase it and post to mailing list as well in next 1-2 days.

OK. We will review it.

> 
> Since, the implementation is started, we will request any subsequent
> comments as an incremental patches.
> 
> > Akhil,
> > 
> > Based on your v2 version, we could map a lot with our HW. However, there
> > are three top level quires for the further review.
> > 
> > 1) Some HW cannot offload all types of packets(like IP fragmented
> > packets) and/or there may have back pressure momentarily from IPSec offload
> > engine (like Queue is full) etc. So in that case what is the expected behavior
> > a) Is it an offload driver responsibility to take care of that or
> > b) Is it passed to application as encrypted packets(in case of inbound)
> > and the application has to take or of them.
> > 
> 
> It will depend on the HW capability. If the HW is not supporting the
> fragmented etc packets, they will come as an encrypted packed to the
> application and application need to take care of them.

OK

> 
> > 2) In case of inbound traffic, What is the packet format from offload
> > driver. i.e
> > a) Will ESP header will be removed from the packet area after the
> > decryption.
> > 
> It depend on the session action type. e.g. for inline crypto, the header
> will be intact. for inline proto, the headers will be removed.
> In any case, we need to improve the documentation.

I thought, we need to keep the header in both cases otherwise the
application may not able to check anti-replay if ESP header removed.

> 
> > 3) We have a few feature like, anti-replay check, SA expiry((byte/time)
> > notification, etc from HW/FW. So it is not clear from the specification
> > on the contract between between offload driver vs application
> > responsibility? Can you give some insight on that? Especially
> > the error notification scheme if it is an offload driver responsibility.
> > 
> 
> Anti-replay, SA expiry management is still in my todo  list.
> The responsibilities will depend on the amount of offloading the HW/FW is
> offering. The current intent is that SA management and expiry is being
> managed by the applicaiton. However, SA expiry event for byte based SA will
> be passed by the HW/FW to application.
> 
> In short, the current focus is covering the basic support  only. Rest will
> be incremental.


Makes sense. This is the hard part to solve in inline HW IPSec implementation.
I suggest to keep API experimental till we solve this hard problems which are
tightly coupled with HW capabilities.

      reply	other threads:[~2017-09-11 18:10 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-10  7:35 [dpdk-dev] [RFC 0/7] ipsec inline Boris Pismenny
2017-07-10  7:35 ` [dpdk-dev] [RFC 1/7] ethdev: add device ipsec encrypt/decrypt capability flags Boris Pismenny
2017-07-10  7:35 ` [dpdk-dev] [RFC 2/7] ethdev: Add ESP header to generic flow steering Boris Pismenny
2017-07-10  7:35 ` [dpdk-dev] [RFC 3/7] ethdev: add rte flow action for crypto Boris Pismenny
2017-07-10  7:35 ` [dpdk-dev] [RFC 4/7] cryptodev: add ipsec xform Boris Pismenny
2017-07-10  7:35 ` [dpdk-dev] [RFC 5/7] mbuf: Add IPsec crypto flags Boris Pismenny
2017-07-10  7:35 ` [dpdk-dev] [RFC 6/7] mbuf: Added next_esp_proto field Boris Pismenny
2017-07-10  7:35 ` [dpdk-dev] [RFC 7/7] example/ipsec_gw: Support SA offload in datapath Boris Pismenny
2017-07-11 17:06 ` [dpdk-dev] [RFC 0/7] ipsec inline Declan Doherty
2017-07-12 14:08   ` Boris Pismenny
2017-07-14 11:12   ` Akhil Goyal
2017-07-25 11:21     ` [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload Akhil Goyal
2017-07-25 11:21       ` [dpdk-dev] [RFC PATCH 1/1] rte_security: proposal Akhil Goyal
2017-07-26 13:46       ` [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload Declan Doherty
2017-08-02 13:16         ` Hemant Agrawal
2017-08-03 11:25           ` Akhil Goyal
2017-08-15  6:35       ` [dpdk-dev] [RFC PATCH v2 0/4] " Akhil Goyal
2017-08-15  6:35         ` [dpdk-dev] [RFC PATCH 1/4] rte_security: API definitions Akhil Goyal
2017-08-15 11:04           ` Radu Nicolau
2017-08-16  7:39             ` Akhil Goyal
2017-08-16 15:40               ` Hemant Agrawal
2017-08-18  9:16                 ` Thomas Monjalon
2017-08-18 12:20                   ` Hemant Agrawal
2017-08-21 10:32                   ` Boris Pismenny
2017-08-21 10:54                     ` Akhil Goyal
2017-08-15  6:35         ` [dpdk-dev] [RFC PATCH 2/4] cryptodev: entend cryptodev to support security APIs Akhil Goyal
2017-08-15  6:35         ` [dpdk-dev] [RFC PATCH 3/4] crypto/dpaa2_sec: add support for protocol offload ipsec Akhil Goyal
2017-08-15  6:35         ` [dpdk-dev] [RFC PATCH 4/4] example/ipsec-secgw: add support for offloading crypto op Akhil Goyal
2017-08-29 14:49       ` [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload Thomas Monjalon
2017-08-31  9:37         ` Akhil Goyal
2017-08-31 10:06           ` Thomas Monjalon
2017-08-31 10:52             ` Akhil Goyal
2017-08-31 13:14               ` Thomas Monjalon
2017-08-31 14:09                 ` Radu Nicolau
2017-09-06 15:53                   ` Jerin Jacob
2017-09-08 11:12                     ` Akhil Goyal
2017-09-11 18:10                       ` Jerin Jacob [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170911181024.GC26002@jerin \
    --to=jerin.jacob@caviumnetworks.com \
    --cc=akhil.goyal@nxp.com \
    --cc=andriy.berestovskyy@cavium.com \
    --cc=aviadye@mellanox.com \
    --cc=balasubramanian.manoharan@cavium.com \
    --cc=borisp@mellanox.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=pathreya@caviumnetworks.com \
    --cc=radu.nicolau@intel.com \
    --cc=sandeep.malik@nxp.com \
    --cc=suheil.chandran@cavium.com \
    --cc=sunil.kulkarni@cavium.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).