[dpdk-dev,07/11] ethdev: add rte flow action for crypto

Message ID 20170914082651.26232-8-akhil.goyal@nxp.com (mailing list archive)
State Superseded, archived
Headers

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK

Commit Message

Akhil Goyal Sept. 14, 2017, 8:26 a.m. UTC
  From: Boris Pismenny <borisp@mellanox.com>

The crypto action is specified by an application to request
crypto offload for a flow.

Signed-off-by: Boris Pismenny <borisp@mellanox.com>
Signed-off-by: Aviad Yehezkel <aviadye@mellanox.com>
---
 lib/librte_ether/rte_flow.h | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)
  

Comments

Jerin Jacob Sept. 21, 2017, 9:16 a.m. UTC | #1
-----Original Message-----
> Date: Thu, 14 Sep 2017 13:56:47 +0530
> From: Akhil Goyal <akhil.goyal@nxp.com>
> To: dev@dpdk.org
> CC: declan.doherty@intel.com, pablo.de.lara.guarch@intel.com,
>  hemant.agrawal@nxp.com, radu.nicolau@intel.com, borisp@mellanox.com,
>  aviadye@mellanox.com, thomas@monjalon.net, sandeep.malik@nxp.com,
>  jerin.jacob@caviumnetworks.com
> Subject: [PATCH 07/11] ethdev: add rte flow action for crypto
> X-Mailer: git-send-email 2.9.3
> 
> From: Boris Pismenny <borisp@mellanox.com>

Hi Boris,

> 
> The crypto action is specified by an application to request
> crypto offload for a flow.
> 
> Signed-off-by: Boris Pismenny <borisp@mellanox.com>
> Signed-off-by: Aviad Yehezkel <aviadye@mellanox.com>
> ---
>  lib/librte_ether/rte_flow.h | 30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
> index ea08af6..dce92ca 100644
> --- a/lib/librte_ether/rte_flow.h
> +++ b/lib/librte_ether/rte_flow.h
> @@ -941,6 +941,13 @@ enum rte_flow_action_type {
>  	 * See struct rte_flow_action_vf.
>  	 */
>  	RTE_FLOW_ACTION_TYPE_VF,
> +	/**
> +	 * Redirects packets to security engine of current device for security
> +	 * processing as specified by security session.
> +	 *
> +	 * See struct rte_flow_action_security.
> +	 */
> +	RTE_FLOW_ACTION_TYPE_SECURITY
>  };
>  
>  /**
> @@ -1034,6 +1041,29 @@ struct rte_flow_action_vf {
>  };
>  
>  /**
> + * RTE_FLOW_ACTION_TYPE_SECURITY
> + *
> + * Perform security action on define flow as specified by security session.
> + * The security session specified in the action must be created on the same port
> + * as the flow action that is being specified.
> + *
> + * The ingress/egress flow attribute should match that specified in the

We do HW CAMs at ingress side to specify the action like
RTE_FLOW_ACTION_TYPE_SECURITY. But, egress side there is NO for HW CAM
for RTE_FLOW_ACTION_TYPE_SECURITY(meaning flow to SA lookup). If I
understand it correctly, Intel has the similar situation and that is the
reason for adding rte_security_set_pkt_metadata() to fix up something in
outbound or inbound. Is it a correct interpretation?

Something like below in ipsec-gw application for
RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL outbound case.

296,6 +296,11 @@ ipsec_enqueue(ipsec_xform_fn xform_func, struct
ipsec_ctx *ipsec_ctx,
                       }
                        break;
                case RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
+                       /* Some ports require SA for inline IPsec */
+                       if (sa->port_needs_md)
+                               rte_security_set_pkt_metadata(
+                                       sa->port_md_uid,
+                                       sa->sec_session, pkts[i], sa);
                        break;




> + * security session if the security session supports the definition of the
> + * direction.
> + *
> + * Multiple flows can be configured to use the same security session. For
> + * example if the security session specifies an egress IPsec SA, then multiple
> + * flows can be specified to that SA. In the case of an ingress IPsec SA then
> + * it is only valid to have a single flow to map to that security session.
> + *
> + *
> + * Non-terminating by default.
> + */
> +struct rte_flow_action_security {
> +	void *security_session; /**< Pointer to security session structure. */
> +};
> +
> +/**
>   * Definition of a single action.
>   *
>   * A list of actions is terminated by a END action.
> -- 
> 2.9.3
>
  
Boris Pismenny Sept. 21, 2017, 4:53 p.m. UTC | #2
Hi Jern,

> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Thursday, September 21, 2017 12:16
> To: Akhil Goyal <akhil.goyal@nxp.com>
> Cc: dev@dpdk.org; declan.doherty@intel.com;
> pablo.de.lara.guarch@intel.com; hemant.agrawal@nxp.com;
> radu.nicolau@intel.com; Boris Pismenny <borisp@mellanox.com>; Aviad
> Yehezkel <aviadye@mellanox.com>; Thomas Monjalon
> <thomas@monjalon.net>; sandeep.malik@nxp.com
> Subject: Re: [PATCH 07/11] ethdev: add rte flow action for crypto
> 
> -----Original Message-----
> > Date: Thu, 14 Sep 2017 13:56:47 +0530
> > From: Akhil Goyal <akhil.goyal@nxp.com>
> > To: dev@dpdk.org
> > CC: declan.doherty@intel.com, pablo.de.lara.guarch@intel.com,
> > hemant.agrawal@nxp.com, radu.nicolau@intel.com,
> borisp@mellanox.com,
> > aviadye@mellanox.com, thomas@monjalon.net,
> sandeep.malik@nxp.com,
> > jerin.jacob@caviumnetworks.com
> > Subject: [PATCH 07/11] ethdev: add rte flow action for crypto
> > X-Mailer: git-send-email 2.9.3
> >
> > From: Boris Pismenny <borisp@mellanox.com>
> 
> Hi Boris,
> 
> >
> > The crypto action is specified by an application to request crypto
> > offload for a flow.
> >
> > Signed-off-by: Boris Pismenny <borisp@mellanox.com>
> > Signed-off-by: Aviad Yehezkel <aviadye@mellanox.com>
> > ---
> >  lib/librte_ether/rte_flow.h | 30 ++++++++++++++++++++++++++++++
> >  1 file changed, 30 insertions(+)
> >
> > diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
> > index ea08af6..dce92ca 100644
> > --- a/lib/librte_ether/rte_flow.h
> > +++ b/lib/librte_ether/rte_flow.h
> > @@ -941,6 +941,13 @@ enum rte_flow_action_type {
> >  	 * See struct rte_flow_action_vf.
> >  	 */
> >  	RTE_FLOW_ACTION_TYPE_VF,
> > +	/**
> > +	 * Redirects packets to security engine of current device for security
> > +	 * processing as specified by security session.
> > +	 *
> > +	 * See struct rte_flow_action_security.
> > +	 */
> > +	RTE_FLOW_ACTION_TYPE_SECURITY
> >  };
> >
> >  /**
> > @@ -1034,6 +1041,29 @@ struct rte_flow_action_vf {  };
> >
> >  /**
> > + * RTE_FLOW_ACTION_TYPE_SECURITY
> > + *
> > + * Perform security action on define flow as specified by security session.
> > + * The security session specified in the action must be created on
> > + the same port
> > + * as the flow action that is being specified.
> > + *
> > + * The ingress/egress flow attribute should match that specified in
> > + the
> 
> We do HW CAMs at ingress side to specify the action like
> RTE_FLOW_ACTION_TYPE_SECURITY. But, egress side there is NO for HW
> CAM for RTE_FLOW_ACTION_TYPE_SECURITY(meaning flow to SA lookup). If
> I understand it correctly, Intel has the similar situation and that is the reason
> for adding rte_security_set_pkt_metadata() to fix up something in outbound
> or inbound. Is it a correct interpretation?

Yes, that's correct. 

Please note that rte_flow is only the control path. It is called once per SA for setting
up offload. The data-path uses the security flags at mbuf->ol_flags and the metadata
that's required for some devices.

> 
> Something like below in ipsec-gw application for
> RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL outbound case.
> 
> 296,6 +296,11 @@ ipsec_enqueue(ipsec_xform_fn xform_func, struct
> ipsec_ctx *ipsec_ctx,
>                        }
>                         break;
>                 case RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
> +                       /* Some ports require SA for inline IPsec */
> +                       if (sa->port_needs_md)
> +                               rte_security_set_pkt_metadata(
> +                                       sa->port_md_uid,
> +                                       sa->sec_session, pkts[i], sa);
>                         break;
> 
> 
> 
> 
> > + * security session if the security session supports the definition
> > +of the
> > + * direction.
> > + *
> > + * Multiple flows can be configured to use the same security session.
> > +For
> > + * example if the security session specifies an egress IPsec SA, then
> > +multiple
> > + * flows can be specified to that SA. In the case of an ingress IPsec
> > +SA then
> > + * it is only valid to have a single flow to map to that security session.
> > + *
> > + *
> > + * Non-terminating by default.
> > + */
> > +struct rte_flow_action_security {
> > +	void *security_session; /**< Pointer to security session structure.
> > +*/ };
> > +
> > +/**
> >   * Definition of a single action.
> >   *
> >   * A list of actions is terminated by a END action.
> > --
> > 2.9.3
> >
  

Patch

diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index ea08af6..dce92ca 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -941,6 +941,13 @@  enum rte_flow_action_type {
 	 * See struct rte_flow_action_vf.
 	 */
 	RTE_FLOW_ACTION_TYPE_VF,
+	/**
+	 * Redirects packets to security engine of current device for security
+	 * processing as specified by security session.
+	 *
+	 * See struct rte_flow_action_security.
+	 */
+	RTE_FLOW_ACTION_TYPE_SECURITY
 };
 
 /**
@@ -1034,6 +1041,29 @@  struct rte_flow_action_vf {
 };
 
 /**
+ * RTE_FLOW_ACTION_TYPE_SECURITY
+ *
+ * Perform security action on define flow as specified by security session.
+ * The security session specified in the action must be created on the same port
+ * as the flow action that is being specified.
+ *
+ * The ingress/egress flow attribute should match that specified in the
+ * security session if the security session supports the definition of the
+ * direction.
+ *
+ * Multiple flows can be configured to use the same security session. For
+ * example if the security session specifies an egress IPsec SA, then multiple
+ * flows can be specified to that SA. In the case of an ingress IPsec SA then
+ * it is only valid to have a single flow to map to that security session.
+ *
+ *
+ * Non-terminating by default.
+ */
+struct rte_flow_action_security {
+	void *security_session; /**< Pointer to security session structure. */
+};
+
+/**
  * Definition of a single action.
  *
  * A list of actions is terminated by a END action.