Re: [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload

[Thomas Monjalon <thomas@monjalon.net>]

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.

> > 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.