From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710071.outbound.protection.outlook.com [40.107.71.71]) by dpdk.org (Postfix) with ESMTP id C70DDDED for ; Mon, 29 Oct 2018 11:19:26 +0100 (CET) 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=NuSvPyWWkOGc01odmkp9G3x3tum6JowIP0+Xos5Q00M=; b=oUpOlD1NnJUMPbOoFk4cA9aif/9p9GtTe7kGhzZ2eaD1MYQb+rdkj8MH/NHNwcMBQuSpmRnEiOfrNvXXIhZcXGVeZMuAiUnslFIty8rpWkuJ4Xfqs9FASw6VEgLJ8Z899Ks4Igept6EcKdq3g+j6BjjrVRLgK8CF2OjhB9FBZr8= Received: from BYAPR07MB4997.namprd07.prod.outlook.com (52.135.238.214) by BYAPR07MB4230.namprd07.prod.outlook.com (52.135.223.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.26; Mon, 29 Oct 2018 10:19:25 +0000 Received: from BYAPR07MB4997.namprd07.prod.outlook.com ([fe80::2d56:eab:242f:fdfc]) by BYAPR07MB4997.namprd07.prod.outlook.com ([fe80::2d56:eab:242f:fdfc%2]) with mapi id 15.20.1273.027; Mon, 29 Oct 2018 10:19:25 +0000 From: Jerin Jacob To: "Ananyev, Konstantin" CC: "dev@dpdk.org" , "Awal, Mohammad Abdul" , "Joseph, Anoob" , "Athreya, Narayana Prasad" Thread-Topic: [dpdk-dev] [RFC v2 5/9] ipsec: add SA data-path API Thread-Index: AQHUX/1c7MgCwavRd0ecHBGPDZ77+aUlrsgAgASkkACABGwdgIAGfJ+AgADllgA= Date: Mon, 29 Oct 2018 10:19:24 +0000 Message-ID: <20181029101905.GB4738@jerin> References: <1535129598-27301-1-git-send-email-konstantin.ananyev@intel.com> <1539109420-13412-6-git-send-email-konstantin.ananyev@intel.com> <20181018173745.GA14157@jerin> <2601191342CEEE43887BDE71AB9772580102FEA53E@IRSMSX106.ger.corp.intel.com> <20181024120346.GA15208@jerin> <2601191342CEEE43887BDE71AB9772580103064BF1@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB9772580103064BF1@irsmsx105.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [111.93.218.67] x-clientproxiedby: BM1PR0101CA0023.INDPRD01.PROD.OUTLOOK.COM (2603:1096:b00:18::33) 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; BYAPR07MB4230; 6:4Zuwnb5MR0wbI1wXcaILhKUv7/SGCsCnCbFD0WjgQ/YDM+ko1akOKmUtvy71luVFnUBvk8Un8h3A6T6GKl1smB4XYApYNoX//8ozzi75Ef9oqFh11LmSaXMR/U7mpcGAnrXEO1Gj8MAgQ0SCYJ5sZ6opxxwZQbD0Qq+R9gX+XAq0p/Nkrwb5ph9nnrGrc3jHxZ5IIZz1FEwkEOYAZiYdkwGJrzPrVTsnsv3bAxUePN/S+nVrICOh/Md1oznARPrw0zngYRekPofA5AesZeKYp7f6PiOiGdlkfjrxaDTq9zGg39fpOcMzTKScCrG8z+iIPC6Ta2OXZEwNE9oEcry4c52dBn/bGEMym7Zrwa6bNg+dkJZbfC2BslFjYWhVI88p1B+32y+Vj8TWqgdK0gCmlYBf2ixMD30coUCXnU7jqbsw16xj8hosHcr2Rfm/rfH1k5PIXBoC5Gz4q+NQ72OdhQ==; 5:8WdzLBoSmgrW5DLRO1G6cTP1OUHW+NqZ6Na7sMJGf3hxgaFmAHhFCeG+Cnhk6ylZc8xPgk222ZW4Yixw3XFKOgNedUD4loXLMLPxjsRP6+lFHCMbM4wnMo8bRqPQnRjyMgZDhv16gl2YY0a6goWX6lxkPhmLtebtd1TaRtFGWIk=; 7:xV/PMpNzftKW3tV527RNpwXhRA/619SFFK7XCC0tjQw9tZ+KERB0SC/VK+prfCgPq4pA/Mrmz0ojAuMtQX0gNpGbQ8AIdUbzjxq2sbVwky/dqF7sFHbu+7RwGhsysG4md0UJJrOVGY51mfkhhE2nwA== x-ms-office365-filtering-correlation-id: 310843e3-6502-457c-83b0-08d63d87fd0e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BYAPR07MB4230; x-ms-traffictypediagnostic: BYAPR07MB4230: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(17755550239193)(192374486261705)(163750095850)(228905959029699); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(10201501046)(3002001)(3231382)(944501410)(52105095)(148016)(149066)(150057)(6041310)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:BYAPR07MB4230; BCL:0; PCL:0; RULEID:; SRVR:BYAPR07MB4230; x-forefront-prvs: 084080FC15 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916004)(346002)(366004)(136003)(376002)(39860400002)(396003)(13464003)(199004)(189003)(5660300001)(54906003)(2906002)(33716001)(25786009)(72206003)(6246003)(8936002)(81166006)(81156014)(229853002)(8676002)(42882007)(107886003)(33656002)(316002)(6436002)(106356001)(4326008)(6512007)(9686003)(105586002)(68736007)(6486002)(446003)(71200400001)(486006)(1076002)(6916009)(186003)(53936002)(71190400001)(11346002)(93886005)(6116002)(256004)(3846002)(476003)(102836004)(97736004)(14444005)(76176011)(26005)(6506007)(386003)(33896004)(52116002)(78486011)(99286004)(5250100002)(14454004)(7736002)(478600001)(66066001)(2900100001)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR07MB4230; 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: 0Q5Xvnh5mI8EmPfZgObeS4UjOd0mc5XDHqKu/K1P7wfeDwLygUKimNo4/zpzSnxAwy/s2cLm3no5WcerysN/6NwKY6xN40lx1T+SuZ5IjesWDkI3pLrqGIUpy0TAOpdwNq2qtSe2D5mFkfoeL8ctdpxs8N+Vs8Tjd+9Ymhn/BEP+JmfJsCYzgMfhXy+WxVQiCsN3fltCIHGwf2i0Eu/lHpg1ixDlYYi5P2zVA7CFtzLfUYJ/mzt/iz17JsaitfCeLwIauvYCkn9IkoGqrXnw+ZkDORCu2GXAZvodDKjwVewlo76Gt1xmo7PGviRMqXDYTlE2lUgoXxs7bjVwwSTKNHX8yEQLnt5kXti61saoqRg= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <30FF27348B86694BB64B69E414D8B452@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-Network-Message-Id: 310843e3-6502-457c-83b0-08d63d87fd0e X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2018 10:19:25.0282 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR07MB4230 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: Mon, 29 Oct 2018 10:19:27 -0000 -----Original Message----- > Date: Sun, 28 Oct 2018 20:37:23 +0000 > From: "Ananyev, Konstantin" > To: Jerin Jacob > CC: "dev@dpdk.org" , "Awal, Mohammad Abdul" > , "Joseph, Anoob" > , "Athreya, Narayana Prasad" > > Subject: RE: [dpdk-dev] [RFC v2 5/9] ipsec: add SA data-path API >=20 >=20 > Hi Jerin, Hi Konstantin, >=20 > > > > > + > > > > > +/** > > > > > + * Checks that inside given rte_ipsec_session crypto/security fi= elds > > > > > + * are filled correctly and setups function pointers based on th= ese values. > > > > > + * @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 th= at can be > > > > > + * 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 belon= g to. > > > > > + * @param mb > > > > > + * The address of an array of *num* pointers to *rte_mbuf* str= uctures > > > > > + * which contain the input packets. > > > > > + * @param cop > > > > > + * The address of an array of *num* pointers to the output *rt= e_crypto_op* > > > > > + * structures. > > > > > + * @param num > > > > > + * The maximum number of packets to process. > > > > > + * @return > > > > > + * Number of successfully processed packets, with error code s= et in rte_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[], uint1= 6_t num) > > > > > +{ > > > > > + return ss->func.prepare(ss, mb, cop, num); > > > > > +} > > > > > + > > > > static inline uint16_t __rte_experimental > > > > rte_ipsec_event_process(const struct rte_ipsec_session *ss, struct = rte_event *ev[], uint16_t num) > > > > { > > > > return ss->func.event_process(ss, ev, num); > > > > } > > > > > > To fulfill that, we can either have 2 separate function pointers: > > > uint16_t (*pkt_process)( const struct rte_ipsec_session *ss, struct r= te_mbuf *mb[],uint16_t num); > > > uint16_t (*event_process)( const struct rte_ipsec_session *ss, struct= rte_event *ev[],uint16_t num); > > > > > > Or we can keep one function pointer, but change it to accept just arr= ay of pointers: > > > uint16_t (*process)( const struct rte_ipsec_session *ss, void *in[],u= int16_t num); > > > and then make session_prepare() to choose a proper function based on = input. > > > > > > I am ok with both schemes, but second one seems a bit nicer to me. > > > > How about best of both worlds, i.e save space and enable compile check > > by anonymous union of both functions > > > > RTE_STD_C11 > > union { > > uint16_t (*pkt_process)( const struct rte_ipsec_session *ss,struc= t rte_mbuf *mb[],uint16_t num); > > uint16_t (*event_process)( const struct rte_ipsec_session *ss, st= ruct rte_event *ev[],uint16_t num); > > }; > > >=20 > Yes, it is definitely possible, but then we still need 2 API functions, > Depending on input type, i.e: >=20 > static inline uint16_t __rte_experimental > rte_ipsec_event_process(const struct rte_ipsec_session *ss, struct rte_ev= ent *ev[], uint16_t num) > { > return ss->func.event_process(ss, ev, num); > } >=20 > static inline uint16_t __rte_experimental > rte_ipsec_pkt_process(const struct rte_ipsec_session *ss, struct rte_mbuf= *mb[], uint16_t num) > { > return ss->func.pkt_process(ss, mb, num); > } >=20 > While if we'll have void *[], we can have just one function for both case= s: >=20 > static inline uint16_t __rte_experimental > rte_ipsec_process(const struct rte_ipsec_session *ss, void *in[], uint16_= t num) > { > return ss->func.process(ss, in, num); > } Since it will be called from different application code path. I would prefer to have separate functions to allow strict compiler check. >=20 > Konstantin