From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [PATCH 07/11] ethdev: add rte flow action for crypto Date: Thu, 21 Sep 2017 14:46:04 +0530 Message-ID: <20170921091600.GA1567@jerin> References: <20170914082651.26232-1-akhil.goyal@nxp.com> <20170914082651.26232-8-akhil.goyal@nxp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dev@dpdk.org, 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 To: Akhil Goyal Return-path: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0040.outbound.protection.outlook.com [104.47.38.40]) by dpdk.org (Postfix) with ESMTP id 7B5EC1B18C for ; Thu, 21 Sep 2017 11:16:28 +0200 (CEST) Content-Disposition: inline In-Reply-To: <20170914082651.26232-8-akhil.goyal@nxp.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" -----Original Message----- > Date: Thu, 14 Sep 2017 13:56:47 +0530 > From: Akhil Goyal > 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 Hi Boris, > > The crypto action is specified by an application to request > crypto offload for a flow. > > Signed-off-by: Boris Pismenny > Signed-off-by: Aviad Yehezkel > --- > 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 >