From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0055.outbound.protection.outlook.com [104.47.0.55]) by dpdk.org (Postfix) with ESMTP id DAE5D1B620 for ; Wed, 4 Oct 2017 12:52:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NEffm53f1EO7rGJAiRgH5Acq7SsrqDxX11Gl+towaWY=; b=eaZLTNKxyzWCtG3SQVB9lSjaez7hjs9YhvuohfwdSHEV5Xzs9Io/YeUFwzshdF+2sGtDRLYLSxM+VHaJMwaYeVO5LOZied95uk9ItAnjz9r+Cxk/yEZZV5rfZT9crOdL2CEIVT8wCHn7sbQW6oNmk6ie3iYqmmq17zGd2/3rp7I= Received: from VI1PR05MB3149.eurprd05.prod.outlook.com (10.170.237.142) by VI1PR05MB3181.eurprd05.prod.outlook.com (10.170.237.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Wed, 4 Oct 2017 10:52:09 +0000 Received: from VI1PR05MB3149.eurprd05.prod.outlook.com ([fe80::3c3c:8f27:30a1:cd59]) by VI1PR05MB3149.eurprd05.prod.outlook.com ([fe80::3c3c:8f27:30a1:cd59%13]) with mapi id 15.20.0077.018; Wed, 4 Oct 2017 10:52:09 +0000 From: Shahaf Shuler To: Akhil Goyal , "dev@dpdk.org" CC: "declan.doherty@intel.com" , "pablo.de.lara.guarch@intel.com" , "hemant.agrawal@nxp.com" , "radu.nicolau@intel.com" , Boris Pismenny , "Aviad Yehezkel" , Thomas Monjalon , "sandeep.malik@nxp.com" , "jerin.jacob@caviumnetworks.com" , "john.mcnamara@intel.com" , "olivier.matz@6wind.com" Thread-Topic: [dpdk-dev] [PATCH v2 06/12] ethdev: extend ethdev to support security APIs Thread-Index: AQHTPEoVRzOKFDS+g0itu8fnrR4jDqLTas2w Date: Wed, 4 Oct 2017 10:52:09 +0000 Message-ID: References: <20170914082651.26232-1-akhil.goyal@nxp.com> <20171003131413.23846-1-akhil.goyal@nxp.com> <20171003131413.23846-7-akhil.goyal@nxp.com> In-Reply-To: <20171003131413.23846-7-akhil.goyal@nxp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=shahafs@mellanox.com; x-originating-ip: [31.154.10.107] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR05MB3181; 6:F8fDANtX6/tVbdXQ0dz5IVZqdzjLAAq8G3ZETlzzpvBoaaXgv90LkIV91S2Qq5mqe7+0rUmZvVODKgSIP7K7Qm4TOuACp9Pdyo4HHracXXUF6FYIe6UNSJPZtL3lp7sc3mZ4/QdBvTqSRJwDTvLqJfNwHNsTzu8T02F9dPiEzSGwX8sWvFEXMzIAGjAu3zFp6/hvd+9QSWPLhU69bMWhg09DZCouAYE1hwxQryD6puoriAF3TGwwGio09S1Qb27McGsgg9bQdYMUtaE1eUM8q+BRs8tjSM0r71dXusb3FnzcmQU82nTi/2/fsKBV1fGPldI2fzBP5wCvoq0Ifr0yjg==; 5:HtcxL80WqPzrIVSofC9PJVC4IBtsM/45RUeWPidiwkNP/eeCD/3Z5ZP34+uWiIdPqhWsIx7qCsBfjlCbVU6GPrKPRbb+O+DfQk7P7lVbPSeNvkXhSBolt4MVvRUiAID4aQVgNk5Srm9jkcvkUv3ugg==; 24:rzSaPUIt9aojttBrlJ/jFNEYbWR5k+IJIeJVSrXJgoZ3jbd2UhxWMd8SEwN6/2Vf5f9B64pLRy8i2ngzsDFyJOc4F9FXpp4M7sK0MIXDNUM=; 7:aQK6mF1pWOQmZsiaEnkBike1RGhaJC7G+zepOsFXyQiStau4O6Rf8kH8xsE3KVyqLJ+tNZmA/mDkWos3j+amONjL7h7Pwwudz9k6oork/bgWkO7SCQsRuVhxPjz+QwuuWmL4ByEU9zsesxx9L6uvYAD4Nsap1PP/Dmn+HKWni9C/NemCpiyyt2SWUJnv4EvQf6yi9zfBlVaRkKpz+cCcpF2pfWSA97d4OrKEfJAr6gk= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 55449135-96bb-4ad6-f92c-08d50b15f620 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR05MB3181; x-ms-traffictypediagnostic: VI1PR05MB3181: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-exchange-antispam-report-test: UriScan:(192374486261705)(228905959029699); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR05MB3181; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR05MB3181; x-forefront-prvs: 0450A714CB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(346002)(376002)(377454003)(189002)(199003)(5250100002)(229853002)(54356999)(4326008)(86362001)(50986999)(7696004)(305945005)(97736004)(105586002)(7736002)(81156014)(76176999)(102836003)(8936002)(110136005)(66066001)(2900100001)(316002)(68736007)(2906002)(81166006)(7110500001)(5660300001)(966005)(2501003)(10710500007)(9686003)(6116002)(3660700001)(189998001)(54906003)(478600001)(7416002)(14454004)(3846002)(33656002)(8656003)(25786009)(74316002)(2420400007)(99286003)(101416001)(3280700002)(6436002)(6306002)(6246003)(15650500001)(6506006)(106356001)(2950100002)(53936002)(53376002)(55016002)(533714002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR05MB3181; H:VI1PR05MB3149.eurprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2017 10:52:09.3743 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR05MB3181 Subject: Re: [dpdk-dev] [PATCH v2 06/12] ethdev: extend ethdev to support security APIs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 10:52:13 -0000 Tuesday, October 3, 2017 4:14 PM, Akhil Goyal: > From: Declan Doherty >=20 > rte_flow_action type and ethdev updated to support rte_security sessions > for crypto offload to ethernet device. >=20 > Signed-off-by: Boris Pismenny > Signed-off-by: Aviad Yehezkel > Signed-off-by: Radu Nicolau > Signed-off-by: Declan Doherty > --- > lib/librte_ether/rte_ethdev.c | 11 +++++++++++ > lib/librte_ether/rte_ethdev.h | 19 +++++++++++++++++-- > lib/librte_ether/rte_ethdev_version.map | 7 +++++++ > 3 files changed, 35 insertions(+), 2 deletions(-) >=20 > diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.= c > index 0597641..f51c5a5 100644 > --- a/lib/librte_ether/rte_ethdev.c > +++ b/lib/librte_ether/rte_ethdev.c > @@ -302,6 +302,17 @@ rte_eth_dev_socket_id(uint8_t port_id) > return rte_eth_devices[port_id].data->numa_node; > } >=20 > +uint16_t > +rte_eth_dev_get_sec_id(uint8_t port_id) { > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -1); > + > + if (rte_eth_devices[port_id].data->dev_flags & > RTE_ETH_DEV_SECURITY) > + return rte_eth_devices[port_id].data->sec_id; > + > + return -1; > +} > + > uint8_t > rte_eth_dev_count(void) > { > diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.= h > index 0adf327..193ad62 100644 > --- a/lib/librte_ether/rte_ethdev.h > +++ b/lib/librte_ether/rte_ethdev.h > @@ -180,6 +180,8 @@ extern "C" { > #include > #include > #include > +#include > + > #include "rte_ether.h" > #include "rte_eth_ctrl.h" > #include "rte_dev_info.h" > @@ -357,7 +359,8 @@ struct rte_eth_rxmode { > jumbo_frame : 1, /**< Jumbo Frame Receipt enable. */ > hw_strip_crc : 1, /**< Enable CRC stripping by hardware. */ > enable_scatter : 1, /**< Enable scatter packets rx handler */ > - enable_lro : 1; /**< Enable LRO */ > + enable_lro : 1, /**< Enable LRO */ > + enable_sec : 1; /**< Enable security offload */ > }; >=20 > /** > @@ -679,8 +682,10 @@ struct rte_eth_txmode { > /**< If set, reject sending out tagged pkts */ > hw_vlan_reject_untagged : 1, > /**< If set, reject sending out untagged pkts */ > - hw_vlan_insert_pvid : 1; > + hw_vlan_insert_pvid : 1, > /**< If set, enable port based VLAN insertion */ > + enable_sec : 1; > + /**< Enable security offload */ Already comment on it in the previous version [1].=20 I don't think there is a justification to introduce new approach to set Tx = offloads given there is already patch set which provides such new API [2]. I think this patch should be on top of it. > }; >=20 > /** > @@ -907,6 +912,7 @@ struct rte_eth_conf { #define > DEV_RX_OFFLOAD_QINQ_STRIP 0x00000020 #define > DEV_RX_OFFLOAD_OUTER_IPV4_CKSUM 0x00000040 > #define DEV_RX_OFFLOAD_MACSEC_STRIP 0x00000080 > +#define DEV_RX_OFFLOAD_SECURITY 0x00000100 >=20 > /** > * TX offload capabilities of a device. > @@ -926,6 +932,8 @@ struct rte_eth_conf { > #define DEV_TX_OFFLOAD_GENEVE_TNL_TSO 0x00001000 /**< Used for > tunneling packet. */ > #define DEV_TX_OFFLOAD_MACSEC_INSERT 0x00002000 > #define DEV_TX_OFFLOAD_MT_LOCKFREE 0x00004000 > +#define DEV_TX_OFFLOAD_SECURITY 0x00008000 > +#define DEV_TX_OFFLOAD_SEC_NEED_MDATA 0x00010000 Isn't it better to have the DEV_TX_OFFLOAD_SEC_NEED_MDATA as part of rte_s= ecurity_capability struct? The "need metadata" should be per security operation indication. For example It is possible that PMD will be able to do IPSEC without the ne= ed in metadata and PDCP with the need in metadata.=20 IMO the better model is for the PMD to advertise it support all kind of sec= urity offloads by setting the DEV_TX_OFFLOAD_SECURITY flag. Application wil= l be able to query more fine-grained capabilities per security operation us= ing rte_security APIs. > /**< Multiple threads can invoke rte_eth_tx_burst() concurrently on the > same > * tx queue without SW lock. > */ > @@ -1651,6 +1659,9 @@ struct rte_eth_dev { > enum rte_eth_dev_state state; /**< Flag indicating the port state */ > } __rte_cache_aligned; >=20 > +uint16_t > +rte_eth_dev_get_sec_id(uint8_t port_id); > + > struct rte_eth_dev_sriov { > uint8_t active; /**< SRIOV is active with 16, 32 or 64 po= ols */ > uint8_t nb_q_per_pool; /**< rx queue number per pool */ > @@ -1711,6 +1722,8 @@ struct rte_eth_dev_data { > int numa_node; /**< NUMA node connection */ > struct rte_vlan_filter_conf vlan_filter_conf; > /**< VLAN filter configuration. */ > + uint16_t sec_id; > + /**< security instance identifier */ > }; >=20 > /** Device supports hotplug detach */ > @@ -1721,6 +1734,8 @@ struct rte_eth_dev_data { #define > RTE_ETH_DEV_BONDED_SLAVE 0x0004 > /** Device supports device removal interrupt */ > #define RTE_ETH_DEV_INTR_RMV 0x0008 > +/** Device supports inline security processing */ > +#define RTE_ETH_DEV_SECURITY 0x0010 I still not understand why this flag is needed.=20 The PMD can advertise its supports rte_security by setting the correspondin= g DEV_TX_OFFLOAD_SECURITY and DEV_RX_OFFLOAD_SECURITY flags. Etherdev layer can validate the sec_id using those flags.=20 The various security offloads, as I mentioned above, should be part of rte_= security_capability query.=20 >=20 > /** > * @internal > diff --git a/lib/librte_ether/rte_ethdev_version.map > b/lib/librte_ether/rte_ethdev_version.map > index 4283728..24cbd7d 100644 > --- a/lib/librte_ether/rte_ethdev_version.map > +++ b/lib/librte_ether/rte_ethdev_version.map > @@ -187,3 +187,10 @@ DPDK_17.08 { > rte_tm_wred_profile_delete; >=20 > } DPDK_17.05; > + > +DPDK_17.11 { > + global: > + > + rte_eth_dev_get_sec_id; > + > +} DPDK_17.08; > -- > 2.9.3 [1] http://dpdk.org/ml/archives/dev/2017-September/076382.html [2] http://dpdk.org/ml/archives/dev/2017-October/077329.html