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
Date: Thu, 31 Aug 2017 15:09:45 +0100 [thread overview]
Message-ID: <94a4b6b5-a80a-9884-244a-02131c695eff@intel.com> (raw)
In-Reply-To: <5392171.j1FdNZENvz@xps>
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.
>
>>> Is there direct Rx/Tx involved in this mode?
>> No the packet will come to the application and will add/remove relevant
>> headers and then send the packet to the appropriate eth dev after route
>> lookup.
>>
>>>> 3. full protocol offload(RTE_SECURITY_SESS_ETH_PROTO_OFFLOAD) - This is
>>>> same as 2 but with protocol support in the ethernet device.
>>> Is there direct Rx/Tx in RTE_SECURITY_SESS_ETH_PROTO_OFFLOAD?
>> No, there should not be direct rx/tx as the application will do route
>> lookup and send the packet to relevant ethernet interface.
>>>> 4. look aside protocol offload(RTE_SECURITY_SESS_CRYPTO_PROTO_OFFLOAD) -
>>>> This is same as 1 but with protocol support in crypto device.
>>> Who is responsible for Rx/Tx in RTE_SECURITY_SESS_CRYPTO_PROTO_OFFLOAD?
>> The packet is returned back to the application as in the case of non
>> protocol offload. But the application doesnt need to take care of the
>> headers and other protocol specifics. It just need to forward the packet
>> to the relevent eth dev after route lookup.
>> Please refer to RFC v2 of the proposal it has more details in the header
>> file rte_security.h and the implementation using the ipsec-secgw
>> application.
>> http://dpdk.org/ml/archives/dev/2017-August/072900.html
> So there is no direct Rx/Tx in any mode?
> What is the point of using an ethdev port if there is no Rx/Tx?
>
>>> [...]
>>>>>> The application can decide using the below action types
>>>>>> enum rte_security_session_action_type {
>>>>>> RTE_SECURITY_SESS_ETH_INLINE_CRYPTO,
>>>>>> /**< Crypto operations are performed by Network interface */
>>>>> In this mode, the ethdev port does the same thing as a crypto port?
>>>> not exactly everything. In this mode, only cipher and auth operations
>>>> are performed by the eth device. No intelligence about the protocol is
>>>> done. This is similar to what the current implementation do with the
>>>> crypto device(Non protocol offload).
>>> Are you saying no but yes?
>>> I say "ethdev port does the same thing as a crypto port"
>>> You say "similar to what the current implementation do with the crypto device"
>> This is said so because the crypto device may also support protocol offload.
>>>>>> RTE_SECURITY_SESS_ETH_PROTO_OFFLOAD,
>>>>>> /**< Crypto operations with protocol support are performed
>>>>>> * by Network/ethernet device.
>>>>>> */
>>>>>> RTE_SECURITY_SESS_CRYPTO_PROTO_OFFLOAD,
>>>>>> /**< Crypto operations with protocol support are performed
>>>>>> * by Crypto device.
>>>>>> */
>>>>> I guess the difference between ETH_PROTO_OFFLOAD and CRYPTO_PROTO_OFFLOAD
>>>>> is that we must re-inject packets from CRYPTO_PROTO_OFFLOAD to the NIC?
>>>> yes
>>> OK
>>> Who is responsible to re-inject packets from CRYPTO_PROTO_OFFLOAD to the NIC?
>> Application will do the forwarding after route lookup
>>>>>> RTE_SECURITY_SESS_NONE
>>>>>> /**< Non protocol offload. Application need to manage everything */
>>>>>> };
>>>>> What RTE_SECURITY_SESS_NONE does? It is said to be implemented above.
>>>> It is non protocol offload mentioned above.
>>> How is it different from using cryptodev?
>> No it is not different. It is just to mention that there is no security
>> session involved and the application will use the cryptodev.
> As far as I understand, my vote is a NACK for the current proposal.
next prev parent reply other threads:[~2017-08-31 14:09 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 [this message]
2017-09-06 15:53 ` Jerin Jacob
2017-09-08 11:12 ` Akhil Goyal
2017-09-11 18:10 ` Jerin Jacob
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=94a4b6b5-a80a-9884-244a-02131c695eff@intel.com \
--to=radu.nicolau@intel.com \
--cc=akhil.goyal@nxp.com \
--cc=aviadye@mellanox.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=sandeep.malik@nxp.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).