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

Boris Pismenny borisp at mellanox.com
Thu Sep 21 18:53:00 CEST 2017


Hi Jern,

> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com]
> Sent: Thursday, September 21, 2017 12:16
> To: Akhil Goyal <akhil.goyal at nxp.com>
> Cc: dev at dpdk.org; declan.doherty at intel.com;
> pablo.de.lara.guarch at intel.com; hemant.agrawal at nxp.com;
> radu.nicolau at intel.com; Boris Pismenny <borisp at mellanox.com>; Aviad
> Yehezkel <aviadye at mellanox.com>; Thomas Monjalon
> <thomas at monjalon.net>; sandeep.malik at 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 at nxp.com>
> > To: dev at dpdk.org
> > CC: declan.doherty at intel.com, pablo.de.lara.guarch at intel.com,
> > hemant.agrawal at nxp.com, radu.nicolau at intel.com,
> borisp at mellanox.com,
> > aviadye at mellanox.com, thomas at monjalon.net,
> sandeep.malik at nxp.com,
> > jerin.jacob at 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 at 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 at mellanox.com>
> > Signed-off-by: Aviad Yehezkel <aviadye at 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
> >


More information about the dev mailing list