From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730073.outbound.protection.outlook.com [40.107.73.73]) by dpdk.org (Postfix) with ESMTP id 6B02E1B153 for ; Thu, 18 Oct 2018 19:38:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IEu/SL+Gt1kxVsCFJZzlK/I1x29R3SxkpoAgNNku/bY=; b=C2uW0188SE0q676Kh5NA2PxLVA1IPgIIPI5qtOs7IMcUG1KXO8zavCf7MDH3pRMFFEwQIHSZsgtnqh9jjE7dd81Ps3lDJ0ekdlEDnQy6ZZViFuW3bU2L2Ye4nw0dqMaraoSz1VQLTgrwqquguSF8m93nGQoubWrrjyee+aiUMOE= Received: from BYAPR07MB4997.namprd07.prod.outlook.com (52.135.238.214) by BYAPR07MB4904.namprd07.prod.outlook.com (52.135.205.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.26; Thu, 18 Oct 2018 17:37:59 +0000 Received: from BYAPR07MB4997.namprd07.prod.outlook.com ([fe80::c5c:4d86:b353:175a]) by BYAPR07MB4997.namprd07.prod.outlook.com ([fe80::c5c:4d86:b353:175a%4]) with mapi id 15.20.1228.027; Thu, 18 Oct 2018 17:37:59 +0000 From: Jerin Jacob To: Konstantin Ananyev CC: "dev@dpdk.org" , Mohammad Abdul Awal , "Joseph, Anoob" , "Athreya, Narayana Prasad" Thread-Topic: [dpdk-dev] [RFC v2 5/9] ipsec: add SA data-path API Thread-Index: AQHUX/1c7MgCwavRd0ecHBGPDZ77+aUlUpcA Date: Thu, 18 Oct 2018 17:37:59 +0000 Message-ID: <20181018173745.GA14157@jerin> References: <1535129598-27301-1-git-send-email-konstantin.ananyev@intel.com> <1539109420-13412-6-git-send-email-konstantin.ananyev@intel.com> In-Reply-To: <1539109420-13412-6-git-send-email-konstantin.ananyev@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2401:4900:22f7:1c0b:b290:a0f2:de82:a8f0] x-clientproxiedby: MA1PR01CA0130.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:35::24) To BYAPR07MB4997.namprd07.prod.outlook.com (2603:10b6:a03:5b::22) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR07MB4904; 6:61y+LtkgpPKSjhpNfwIgN/yWCsIlieVnuz0qE2dmokbZxaDUp2jsv+60ydzoutlvityaIzk9SHwv4cm/6/JujH0+YNFbNJhZNtG9rzDYYwpovbyUHiOXyprBvQ/PCNZacxhp9HwLQcVFlK6t7eeB4EY5jzjzVL7a0F0WZmUzRXuVNThj8qKV1k0KcYssG3HKvcSV0nWs3IPqp/jvTpyb6HKmkDs1ZFS1CKSu1ot3zEssVfGpDqppD4fg8cMcIJD9RUfFP8eaROfvndkazN/tfluu0OUsD/J6E2BdJjDjH3vUDzcFUsZaB20ShpdebrfenINbtoMTlcGd0NQCQ0tcWiUfQ1qAOvFkuUUVzB5lc54/E7oS0ITAdxZFcixL7wnIJjXZiOta78uxzB3s00feE9FhV2IcpMefJcJ59J4Ng0DbCm4GOhtAx1e5Y6UY4HL5Mly6nt/JT7Rimu/huT+6+g==; 5:xfxUc9tRQEAtWJuAPzSTHAW3EjsaqfLfvXifKeUsqMNRjkCxAyUzo9mgrwqI04/Byp9FFa96JW9jpU1detCnLX8Vv34MVIlsWmnGTExN/ZrbseZ+QAlN7jP/6eCdsub4vsMbSKKPyOUsMyKLX39UovSs5zVCbsD3mH4oILrt1Fc=; 7:YCp3pSzTO+G/bkin34ecLSeoJ8wvU6+kPsIcuiBpZK2iyNs6IA7TsQeGmjKp7HZ9oq0F1pErKfY0mPpcYyFW+mZYPXyVl5loKQpG7jyN4u7lc2ag3exZlmvJlcyd5pvrrOoICLY/i1jdzxE5SxA9XPOisfv65CCdNaEE2ACeSskgltJnVP5E/cU/mSh6GwaKxqcxppoQKnoZvzLAwXXXTHxJpebv2hHeq0krE69jzA9BD3cctidP/mlhvcnP7PXk x-ms-office365-filtering-correlation-id: 8c42d937-8c56-43c3-29a9-08d6352071f3 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BYAPR07MB4904; x-ms-traffictypediagnostic: BYAPR07MB4904: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(17755550239193)(228905959029699); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(10201501046)(3002001)(3231355)(944501410)(52105095)(149066)(150057)(6041310)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:BYAPR07MB4904; BCL:0; PCL:0; RULEID:; SRVR:BYAPR07MB4904; x-forefront-prvs: 08296C9B35 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916004)(366004)(396003)(376002)(136003)(39860400002)(346002)(13464003)(199004)(189003)(386003)(8676002)(81156014)(81166006)(256004)(4744004)(68736007)(316002)(105586002)(575784001)(14444005)(46003)(8936002)(186003)(4326008)(6916009)(33896004)(229853002)(76176011)(72206003)(6506007)(6436002)(5660300001)(52116002)(6486002)(97736004)(478600001)(106356001)(42882007)(99286004)(102836004)(5250100002)(6512007)(33716001)(107886003)(14454004)(11346002)(476003)(6246003)(71190400001)(446003)(9686003)(71200400001)(33656002)(305945005)(486006)(2900100001)(2906002)(25786009)(53936002)(54906003)(6116002)(7736002)(1076002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR07MB4904; H:BYAPR07MB4997.namprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: uqstjZZddVUKuzsZuPrlEmnlNybkR6OvFwi/Em73H553j6zgqORQJyyBJVRZaLLDYfqa74Mf0Ff48CblrQfi8bgeK7rG4cSuoyuWTc57Kl8Sja/Omu6RwlPtMpmlEOOdTtjeUlAC1mj6+iPv0Gepb4j7fITcQO2GDdv+JqGJH3CfGr8LcwUFgPL3Qcv5MXE1LEfPoBc1SMVeUjG/UXmL0XuS805sDs8Rix6/I73Q8AJoWfo6iy8HKzqJe++qMQRNuc8vR/u9N62kN3ZOtGOqKh5yT7XwEZR52HFwx8iZ7vGfDf0eZTk+/DdHrAzt56fpyPFafZbhyoIr6LefOP/Nd8CUVebrzPeVb4ZG2RJeeS4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <1D04498511E1F34D91D986E9FE197CA1@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8c42d937-8c56-43c3-29a9-08d6352071f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2018 17:37:59.6708 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR07MB4904 Subject: Re: [dpdk-dev] [RFC v2 5/9] ipsec: add SA data-path API 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: Thu, 18 Oct 2018 17:38:03 -0000 -----Original Message----- > Date: Tue, 9 Oct 2018 19:23:36 +0100 > From: Konstantin Ananyev > To: dev@dpdk.org > CC: Konstantin Ananyev , Mohammad Abdul Awa= l > > Subject: [dpdk-dev] [RFC v2 5/9] ipsec: add SA data-path API > X-Mailer: git-send-email 1.7.0.7 >=20 Hi Konstantin, Overall it looks good, but some comments on event mode integration in performance effective way. >=20 > Introduce Security Association (SA-level) data-path API > Operates at SA level, provides functions to: > - initialize/teardown SA object > - process inbound/outbound ESP/AH packets associated with the given S= A > (decrypt/encrypt, authenticate, check integrity, > add/remove ESP/AH related headers and data, etc.). >=20 > Signed-off-by: Mohammad Abdul Awal > Signed-off-by: Konstantin Ananyev > --- > lib/librte_ipsec/Makefile | 2 + > lib/librte_ipsec/meson.build | 4 +- > lib/librte_ipsec/rte_ipsec.h | 154 +++++++++++++++++++++++++++= ++++++ > lib/librte_ipsec/rte_ipsec_version.map | 3 + > lib/librte_ipsec/sa.c | 98 ++++++++++++++++++++- > lib/librte_ipsec/sa.h | 3 + > lib/librte_ipsec/ses.c | 45 ++++++++++ > 7 files changed, 306 insertions(+), 3 deletions(-) > create mode 100644 lib/librte_ipsec/rte_ipsec.h > create mode 100644 lib/librte_ipsec/ses.c >=20 > diff --git a/lib/librte_ipsec/Makefile b/lib/librte_ipsec/Makefile > index 7758dcc6d..79f187fae 100644 > --- a/lib/librte_ipsec/Makefile > +++ b/lib/librte_ipsec/Makefile > @@ -17,8 +17,10 @@ LIBABIVER :=3D 1 >=20 > # all source are stored in SRCS-y > SRCS-$(CONFIG_RTE_LIBRTE_IPSEC) +=3D sa.c > +SRCS-$(CONFIG_RTE_LIBRTE_IPSEC) +=3D ses.c >=20 > # install header files > +SYMLINK-$(CONFIG_RTE_LIBRTE_IPSEC)-include +=3D rte_ipsec.h > SYMLINK-$(CONFIG_RTE_LIBRTE_IPSEC)-include +=3D rte_ipsec_sa.h >=20 > include $(RTE_SDK)/mk/rte.lib.mk > diff --git a/lib/librte_ipsec/meson.build b/lib/librte_ipsec/meson.build > index 52c78eaeb..6e8c6fabe 100644 > --- a/lib/librte_ipsec/meson.build > +++ b/lib/librte_ipsec/meson.build > @@ -3,8 +3,8 @@ >=20 > allow_experimental_apis =3D true >=20 > -sources=3Dfiles('sa.c') > +sources=3Dfiles('sa.c', 'ses.c') >=20 > -install_headers =3D files('rte_ipsec_sa.h') > +install_headers =3D files('rte_ipsec.h', 'rte_ipsec_sa.h') >=20 > deps +=3D ['mbuf', 'net', 'cryptodev', 'security'] > diff --git a/lib/librte_ipsec/rte_ipsec.h b/lib/librte_ipsec/rte_ipsec.h > new file mode 100644 > index 000000000..5c9a1ed0b > --- /dev/null > +++ b/lib/librte_ipsec/rte_ipsec.h > @@ -0,0 +1,154 @@ > +/* SPDX-License-Identifier: BSD-3-Clause > + * Copyright(c) 2018 Intel Corporation > + */ > + > +#ifndef _RTE_IPSEC_H_ > +#define _RTE_IPSEC_H_ > + > +/** > + * @file rte_ipsec.h > + * @b EXPERIMENTAL: this API may change without prior notice > + * > + * RTE IPsec support. > + * librte_ipsec provides a framework for data-path IPsec protocol > + * processing (ESP/AH). > + * IKEv2 protocol support right now is out of scope of that draft. > + * Though it tries to define related API in such way, that it could be a= dopted > + * by IKEv2 implementation. > + */ > + > +#include > +#include > + > +#ifdef __cplusplus > +extern "C" { > +#endif > + > +struct rte_ipsec_session; > + > +/** > + * IPsec session specific functions that will be used to: > + * - prepare - for input mbufs and given IPsec session prepare crypto op= s > + * that can be enqueued into the cryptodev associated with given sessi= on > + * (see *rte_ipsec_crypto_prepare* below for more details). > + * - process - finalize processing of packets after crypto-dev finished > + * with them or process packets that are subjects to inline IPsec offl= oad > + * (see rte_ipsec_process for more details). > + */ > +struct rte_ipsec_sa_func { > + uint16_t (*prepare)(const struct rte_ipsec_session *ss, > + struct rte_mbuf *mb[], > + struct rte_crypto_op *cop[], > + uint16_t num); > + uint16_t (*process)(const struct rte_ipsec_session *ss, > + struct rte_mbuf *mb[], > + uint16_t num); IMO, It makes sense to have separate function pointers for inbound and=20 outbound so that, implementation would be clean and we can avoid a "if" check. > +}; > + > +/** > + * rte_ipsec_session is an aggregate structure that defines particular > + * IPsec Security Association IPsec (SA) on given security/crypto device= : > + * - pointer to the SA object > + * - security session action type > + * - pointer to security/crypto session, plus other related data > + * - session/device specific functions to prepare/process IPsec packets. > + */ > +struct rte_ipsec_session { > + > + /** > + * SA that session belongs to. > + * Note that multiple sessions can belong to the same SA. > + */ > + struct rte_ipsec_sa *sa; > + /** session action type */ > + enum rte_security_session_action_type type; > + /** session and related data */ > + union { > + struct { > + struct rte_cryptodev_sym_session *ses; > + } crypto; > + struct { > + struct rte_security_session *ses; > + struct rte_security_ctx *ctx; > + uint32_t ol_flags; > + } security; > + }; > + /** functions to prepare/process IPsec packets */ > + struct rte_ipsec_sa_func func; > +}; IMO, it can be cache aligned as it is used in fast path. > + > +/** > + * Checks that inside given rte_ipsec_session crypto/security fields > + * are filled correctly and setups function pointers based on these valu= es. > + * @param ss > + * Pointer to the *rte_ipsec_session* object > + * @return > + * - Zero if operation completed successfully. > + * - -EINVAL if the parameters are invalid. > + */ > +int __rte_experimental > +rte_ipsec_session_prepare(struct rte_ipsec_session *ss); > + > +/** > + * For input mbufs and given IPsec session prepare crypto ops that can b= e > + * enqueued into the cryptodev associated with given session. > + * expects that for each input packet: > + * - l2_len, l3_len are setup correctly > + * Note that erroneous mbufs are not freed by the function, > + * but are placed beyond last valid mbuf in the *mb* array. > + * It is a user responsibility to handle them further. > + * @param ss > + * Pointer to the *rte_ipsec_session* object the packets belong to. > + * @param mb > + * The address of an array of *num* pointers to *rte_mbuf* structures > + * which contain the input packets. > + * @param cop > + * The address of an array of *num* pointers to the output *rte_crypto= _op* > + * structures. > + * @param num > + * The maximum number of packets to process. > + * @return > + * Number of successfully processed packets, with error code set in rt= e_errno. > + */ > +static inline uint16_t __rte_experimental > +rte_ipsec_crypto_prepare(const struct rte_ipsec_session *ss, > + struct rte_mbuf *mb[], struct rte_crypto_op *cop[], uint16_t num) > +{ > + return ss->func.prepare(ss, mb, cop, num); > +} > + > +/** > + * Finalise processing of packets after crypto-dev finished with them or > + * process packets that are subjects to inline IPsec offload. > + * Expects that for each input packet: > + * - l2_len, l3_len are setup correctly > + * Output mbufs will be: > + * inbound - decrypted & authenticated, ESP(AH) related headers removed, > + * *l2_len* and *l3_len* fields are updated. > + * outbound - appropriate mbuf fields (ol_flags, tx_offloads, etc.) > + * properly setup, if necessary - IP headers updated, ESP(AH) fields add= ed, > + * Note that erroneous mbufs are not freed by the function, > + * but are placed beyond last valid mbuf in the *mb* array. > + * It is a user responsibility to handle them further. > + * @param ss > + * Pointer to the *rte_ipsec_session* object the packets belong to. > + * @param mb > + * The address of an array of *num* pointers to *rte_mbuf* structures > + * which contain the input packets. > + * @param num > + * The maximum number of packets to process. > + * @return > + * Number of successfully processed packets, with error code set in rt= e_errno. > + */ > +static inline uint16_t __rte_experimental > +rte_ipsec_process(const struct rte_ipsec_session *ss, struct rte_mbuf *m= b[], > + uint16_t num) > +{ > + return ss->func.process(ss, mb, num); > +} Since we have separate functions and different application path for differ= ent mode and the arguments also differ. I think, It is better to integrate event mode like following static inline uint16_t __rte_experimental rte_ipsec_event_process(const struct rte_ipsec_session *ss, struct rte_even= t *ev[], uint16_t num) { return ss->func.event_process(ss, ev, num); } This is to, 1) Avoid Event mode application code duplication 2) Better I$ utilization rather moving event specific and mbuff specific at different code locations 3) Better performance as inside one function pointer we can do things in one shot rather splitting the work to application and library. 4) Event mode has different modes like ATQ, non ATQ etc, These things we can abstract through exiting function pointer scheme. 5) atomicity & ordering problems can be sorted out internally with the even= ts, having one function pointer for event would be enough. We will need some event related info (event dev, port, atomic queue to use etc) which need to be added in rte_ipsec_session *ss as UNION so it wont impact the normal mode. This way, all the required functionality of th= is library=20 can be used with event-based model. See below some implementation thoughts on this. > + > +#ifdef __cplusplus > +} > +#endif > + > +#endif /* _RTE_IPSEC_H_ */ > diff --git a/lib/librte_ipsec/rte_ipsec_version.map b/lib/librte_ipsec/rt= e_ipsec_version.map > +const struct rte_ipsec_sa_func * > +ipsec_sa_func_select(const struct rte_ipsec_session *ss) > +{ > + static const struct rte_ipsec_sa_func tfunc[] =3D { > + [RTE_SECURITY_ACTION_TYPE_NONE] =3D { > + .prepare =3D lksd_none_prepare, > + .process =3D lksd_none_process, > + }, > + [RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO] =3D { > + .prepare =3D NULL, > + .process =3D inline_crypto_process, > + }, > + [RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL] =3D { > + .prepare =3D NULL, > + .process =3D inline_proto_process, > + }, > + [RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL] =3D { > + .prepare =3D lksd_proto_prepare, > + .process =3D lksd_proto_process, > + }, [RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL][EVENT] =3D { .prepare =3D NULL, .process =3D NULL, .process_evt =3D lksd_event_process, }, [RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL][EVENT] =3D { .prepare =3D NULL, .process =3D NULL, .process_evt =3D inline_event_process, }, Probably add one more dimension in array to choose event/poll?=20 > + }; > + > + if (ss->type >=3D RTE_DIM(tfunc)) > + return NULL; > + > + return tfunc + ss->type; > +} > diff --git a/lib/librte_ipsec/sa.h b/lib/librte_ipsec/sa.h > index ef030334c..13a5a68f3 100644 > --- a/lib/librte_ipsec/sa.h > +++ b/lib/librte_ipsec/sa.h > @@ -72,4 +72,7 @@ struct rte_ipsec_sa { >=20 > } __rte_cache_aligned; >=20 > +const struct rte_ipsec_sa_func * > +ipsec_sa_func_select(const struct rte_ipsec_session *ss); > + > #endif /* _SA_H_ */ > diff --git a/lib/librte_ipsec/ses.c b/lib/librte_ipsec/ses.c > new file mode 100644 > index 000000000..afefda937 > --- /dev/null > +++ b/lib/librte_ipsec/ses.c > @@ -0,0 +1,45 @@ > +/* SPDX-License-Identifier: BSD-3-Clause > + * Copyright(c) 2018 Intel Corporation > + */ > + > +#include > +#include "sa.h" > + > +static int > +session_check(struct rte_ipsec_session *ss) > +{ > + if (ss =3D=3D NULL) > + return -EINVAL; > + > + if (ss->type =3D=3D RTE_SECURITY_ACTION_TYPE_NONE) { > + if (ss->crypto.ses =3D=3D NULL) > + return -EINVAL; > + } else if (ss->security.ses =3D=3D NULL || ss->security.ctx =3D= =3D NULL) > + return -EINVAL; > + > + return 0; > +} > + > +int __rte_experimental > +rte_ipsec_session_prepare(struct rte_ipsec_session *ss) > +{ Probably add one more argument to choose event vs poll so that above function pointers can be selected. or have different API like rte_ipsec_use_mode(EVENT) or API other slow path scheme to select the mode.=20 > + int32_t rc; > + const struct rte_ipsec_sa_func *fp; > + > + rc =3D session_check(ss); > + if (rc !=3D 0) > + return rc; > + > + fp =3D ipsec_sa_func_select(ss); > + if (fp =3D=3D NULL) > + return -ENOTSUP; > + > + ss->func =3D fp[0]; > + > + if (ss->type =3D=3D RTE_SECURITY_ACTION_TYPE_NONE) > + ss->crypto.ses->userdata =3D (uintptr_t)ss; > + else > + ss->security.ses->userdata =3D (uintptr_t)ss; > + > + return 0; > +} > -- > 2.13.6 >=20