Message ID | 20170914082651.26232-8-akhil.goyal@nxp.com (mailing list archive) |
---|---|
State | Superseded, archived |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EC9781041; Thu, 14 Sep 2017 10:29:40 +0200 (CEST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0043.outbound.protection.outlook.com [104.47.42.43]) by dpdk.org (Postfix) with ESMTP id BC5DE1B1BF for <dev@dpdk.org>; Thu, 14 Sep 2017 10:29:38 +0200 (CEST) Received: from DM5PR03CA0045.namprd03.prod.outlook.com (2603:10b6:4:3b::34) by SN2PR03MB2365.namprd03.prod.outlook.com (2603:10b6:804:e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Thu, 14 Sep 2017 08:29:37 +0000 Received: from BN1AFFO11FD023.protection.gbl (2a01:111:f400:7c10::187) by DM5PR03CA0045.outlook.office365.com (2603:10b6:4:3b::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.8 via Frontend Transport; Thu, 14 Sep 2017 08:29:37 +0000 Authentication-Results: spf=fail (sender IP is 192.88.168.50) smtp.mailfrom=nxp.com; NXP1.onmicrosoft.com; dkim=none (message not signed) header.d=none;NXP1.onmicrosoft.com; dmarc=fail action=none header.from=nxp.com; Received-SPF: Fail (protection.outlook.com: domain of nxp.com does not designate 192.88.168.50 as permitted sender) receiver=protection.outlook.com; client-ip=192.88.168.50; helo=tx30smr01.am.freescale.net; Received: from tx30smr01.am.freescale.net (192.88.168.50) by BN1AFFO11FD023.mail.protection.outlook.com (10.58.52.83) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.20.13.11 via Frontend Transport; Thu, 14 Sep 2017 08:29:36 +0000 Received: from netperf2.ap.freescale.net ([10.232.133.164]) by tx30smr01.am.freescale.net (8.14.3/8.14.0) with ESMTP id v8E8T36L025953; Thu, 14 Sep 2017 01:29:32 -0700 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> Date: Thu, 14 Sep 2017 13:56:47 +0530 Message-ID: <20170914082651.26232-8-akhil.goyal@nxp.com> X-Mailer: git-send-email 2.9.3 In-Reply-To: <20170914082651.26232-1-akhil.goyal@nxp.com> References: <20170914082651.26232-1-akhil.goyal@nxp.com> X-EOPAttributedMessage: 0 X-Matching-Connectors: 131498513768253183; (91ab9b29-cfa4-454e-5278-08d120cd25b8); () X-Forefront-Antispam-Report: CIP:192.88.168.50; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(336005)(39860400002)(39380400002)(376002)(346002)(2980300002)(1110001)(1109001)(339900001)(189002)(199003)(47776003)(189998001)(48376002)(36756003)(86362001)(50986999)(50466002)(76176999)(5003940100001)(2950100002)(6916009)(6666003)(77096006)(7416002)(68736007)(5660300001)(105606002)(33646002)(106466001)(2906002)(81156014)(81166006)(8676002)(2351001)(54906002)(1076002)(50226002)(8936002)(85426001)(4326008)(305945005)(356003)(110136004)(8656003)(498600001)(53936002)(316002)(104016004)(97736004)(16586007); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2365; H:tx30smr01.am.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD023; 1:9lacS2lS9kaJrZLoHqrliE6jZ7SPB4ELrhfJhdATLWCZWrA5C12KBG8ao4LnpVQ0dpRrfQ287l4AB+/S/cNE2X7+oJyJucGYXogDc4V/tGySAz2kH4HVq4N/8JBpf+Ae MIME-Version: 1.0 Content-Type: text/plain X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9843344a-4117-487a-443d-08d4fb4abc18 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(300000503095)(300135400095)(2017052603199)(201703131430075)(201703131517081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN2PR03MB2365; X-Microsoft-Exchange-Diagnostics: 1; SN2PR03MB2365; 3:K9i1IzqGCVl7cnJ4zIW0sDGKgW0FXlxOQ+zffF4oG6kvv03FTMwFlHsoztLv7S0Do4fsHaG3C0XHjzWzcpy0c+PwBsIkzqisw2mOmiKDL1a/rWtcH7wUeYPv4oci9u3dlLYm1Jsr47apFjgm2WPqT0t3xhU8lgkN9hUwfCpnQ8+xt/9izbGQtbU9z8uGz3uZFSG24eEB+uFPUNMMQiqKiLakptk8nhPOchX6d9HN+27YBJNXWfmaB9wrlPJzAl1rUXhYXeIZWMYreMiogQB7fXiLNrkbCgyn6QmyEqQ9+kJ+6eSL1L9OnHUxseihuSMLcRYZSoZSsmOU2dMwdceJMycwYKyjcu4roWHq3xMpXUI=; 25:M6qwL9rY6hU2ZJ5hkU996WESOaQvyQlDQRQ+qJ46Y8zkGmTcxbOg6thl2BY2jmxHFhiihPZIUokMsGRl3r2j8yu8fnJrcy7vs5q2ZZW7AqbcqahZ0EOczyq0HRlBRXcpo0jT9mwJ+055kVHtKA0pNtl2TbVVJuyQ/OGYh6Y1uJZWXI1a4aBxXeVupFRcEoyIsrYgMMbDyZhY/s9tNfq4wjGvQDbiDEGhDiR0TIdjD/KqRHed1V6YWtiGDHiGAhoe3L+71wc85bYDyqHCoaWhqBETxAIxb7CMyvZEHdRn6wQ1h29K0eutXfQD5qax5MsQf9nzSaZRu179jvL6TqyVPw== X-MS-TrafficTypeDiagnostic: SN2PR03MB2365: X-Microsoft-Exchange-Diagnostics: 1; SN2PR03MB2365; 31:XOGG+p1DFG/ZMA5zMZXArDx78FzwCHAo5743fZeYOZbHOoG23LXznDVeOwSZCchRitLRk3e8fLoQBm7K8d7QnTth6IC4Me0Ktvu2TGri8Hb3RTZeHdYcV5qjzWdeJoa5oThh5h621oIDVQzSHsAUkuwLEzIgb99IFSAoLwbjLIMp8NEJHgEeBbB6WxJgKbVVgRqtsCyBSL1yjrg6IHVVsn7pinVBSr7WnJwrMHeWdb4=; 4:rUnBz0VIjVNea8CuXulwnfEfxatfNtQel9UEiJu7nAF6c11aX758JeagBCU+o48ogO0Gs2B4P6pM1sMXPwOOt1ghEuNb2ixSopUgECiKbUaMtWBAGbrkesRypK23Aa7u51fGQ2Ydo9LxBYfK7taw/3jTEZrlTDK4bOd0nbyMvym1yrA4eTgqZkpdV/9PmiJQ2SHc3ztKb4fqoLv1QQdbrLm/QpiADzAL6WMYaarUTzrukN/k6+OA1wjnGTOSXoiPWUBxAWOZ9PxlzhTX2BlCuiok4tFy/06NqQiN5k4uNsw= X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Microsoft-Antispam-PRVS: <SN2PR03MB236503586C3FC9357D6D7B6FE66F0@SN2PR03MB2365.namprd03.prod.outlook.com> X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6095135)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6096035)(20161123565025)(20161123556025)(201703131430075)(201703131448075)(201703131433075)(201703161259150)(201703151042153)(20161123561025)(20161123563025)(20161123559100)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR03MB2365; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(400006)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR03MB2365; X-Forefront-PRVS: 0430FA5CB7 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR03MB2365; 23:PWerpYg0A8fRFrj0+IWeVkHDUd0phS704/y9dgIW6?= 5fqXMyBxravUiMXApPECRWrwHgl52b2/rR39WuhX5K7y+tE6xlYz2kdrbeys5PDeT8+Q9Rdtd2deLvbuj/KCmvaSAbSoufVwIIaKenwPbl0A/0qapkXWIWja1TH/zeah8hM5siQuxflbvFgXtM2C1siwijGxv8KejY/E1J3vxbX1tQJt7/REj2OElferbNFuwZlHjP9+WnffbUqhOanri4CMne19KldaGLXPmM+CSgmK18YHnuydkRsJUg5FpgU8RZkNSj5Yenmef5GYAgZJCwatdKdVRxEFxrOrGvTSt2mvZxgn43No03x/7z8X/Qqa3FlQC+nQJfTZbPWQUWriBq9uWY46wBuM1IXSbRLLcIy70AlJrTPgoT2I9JyciyujXSKorA86lKLzuPtK1hS66bWWwHtlEMUA8rOmhuS4tMWyTHC8yRGhXNKY+9eBXvM2+wwlcwKgZJdCS02jqisQrO2phg23wudT1Tos0DrB0hxsRZTpttyQ4d9ghZFLpi/VFYJlOD4jAvjcPorRqtjKHlkcMHHUIIoimqla5bCv+zltOWcUpqjq3sWClOQaEEt4y+vo1ZufYlsbvs2K3hC5g6BOA8ZPcE7I2ALhJa4FpnNBsf3lkgXlbb3ywtOJz1gD7MvWQIZktPEYmuNGTSk2wJGEFVHyZgsSdJFBSyB60e2sgIES3CZDgz7hVqEOyTe5dd3kOkqq17ryQrI7roP3+Br2+ETSf3uXPam5qHFxtqCOXsuMc4CkGEQo9cj1NbJtr3yMhbIJZkGDcNt+sQQi9SKaV10+SYa1NtFaTZ4Icm1ZBcjHcWx5JGWSfOiL/pKUMy8jLqJ3MH7xuA46SUSv4omkz7Wpr5yfb05pQKDxEL+b57FwXev12tVItmi4/kYJnW2TkwwmfyQKtPzmDOhQj5pQXYUa/9NTea8yqAwwUnhdjvUQkbKQsVYC6CtmE6Csz+x7ni05gE30QqGrvji0xzbnJypuUGwt+0XHqMeNXwoAQYbvSsvBxoS248dAksctHghiCj4evaGYzIb0WuvU2wUJTsKrUtgx5+U+R3bQuUCzeIyYaPNjeg4K4dhfsjOdkD+r0CmWcVm1x0AvhVXMOmIkkgOyng1K4+bvjv5qtZn2z6IoBMIH6FRJw+Iyw7Kq/zuq466bgslO2uBJ1DwpZrAugPFLNwutgu5oIAsoVn8nw== X-Microsoft-Exchange-Diagnostics: 1; SN2PR03MB2365; 6:GJHSkn9AAwXu8Z2nHyd1C9Si22RzTl49KiHKaiTx3c1tJrQXrf2BrshvstrV6ckXVCNM/1qRs3/twxx/AF5k/CpQGntt8VOw6Egcx24khPZROR8kN4np2QS9gLgqep4AS+Ou/2ZWeb1/lgWY2la72zYDP2jFIMobN9V5JmPD8s3dq3F/bYt2VIhx2I704KqNGAQkLOwdNjVG+IUNtaX3M9uajOK+bpCSLdN/V+kG9XrlH+GS+kNHMjqYFKMiPPo9opK8kkKxTw62rD/Jil+GCeoIi1bhoGWrDzUF4lJBuu9HcmmxKXXcWxEItodnzPwoHYNwM5hsC5y30OqciHoCLg==; 5:8uhO/gbEZ6MvYAzFAaDklbvaBOln98bECfC4FqIOi7fhb4CV8y+GK2b0c8FpJSw5wLVjxkmyu1n/gSi7yKZgsjXcr0iWTp2qMDhxlHB/dZo4EphVygzgf6w/vhfdcmEKF7rc3OCf3AKSZ/2RO6h3SQ==; 24:uyOs2rSkpJOPIxGLg//TOfYUOA7DN9RfD75Mqny/2GPApnfsuOTZW2XQprxAIO+C2S7c9nWD05tl2gY5Ka3K9jjpm13/APoTA09PhNbhyAM=; 7:STcNN1MORJFsE4oaoKbPONkK1hpVvb+bvpWGO4UTw6Y4zY+gWR4twLztTo3BkATy7Xxg+iP56ux8SD3CgzZPVd0TtZlVz8WFpc3S+75kVo5DN301jNrf8uoP/DyRFnPj5/OTVNgMeRPK3IYU2As5Y7JE/20IIMfA7zgDBsMZuc6kfQDGnVJAF8VY/mu+ukI0YiFHakIEmM3XUqP6zf3e3bQKqeZKa95y/br+770bxiw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2017 08:29:36.6381 (UTC) X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[192.88.168.50]; Helo=[tx30smr01.am.freescale.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2365 Subject: [dpdk-dev] [PATCH 07/11] ethdev: add rte flow action for crypto X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
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
-----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 >
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 > >
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.