From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700069.outbound.protection.outlook.com [40.107.70.69]) by dpdk.org (Postfix) with ESMTP id 7137ADED for ; Wed, 31 Oct 2018 07:37:08 +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=G8+DB1qY9AWUzFTD/YxbCSDoWzITiCaeRBVs/d5zH9g=; b=DW+BB7/w00xfe1V35Yg7OIQMeCXtupxD7c63EEYiF+pbbQAjlL0TR/FjwO0QRB6JOO/7B1WXlAJFsnEa8j1NxuuPXNtJcOvMu5d/WMkk/uKj4cp2stq+w115Q9Hn54bIQR+II01ibOu6PplAfLICa5lPmYX04US/Ris/TsLk9F4= 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; Wed, 31 Oct 2018 06:37:07 +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; Wed, 31 Oct 2018 06:37:07 +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+AgAFByICAAXIKAIABGFkA Date: Wed, 31 Oct 2018 06:37:06 +0000 Message-ID: <20181031063653.GA22275@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> <20181029101905.GB4738@jerin> <2601191342CEEE43887BDE71AB97725801030661D4@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB97725801030661D4@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: BM1PR01CA0128.INDPRD01.PROD.OUTLOOK.COM (2603:1096:b00:40::22) 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:KFz4lkDfug0bXCbpvjeerNXF+6pE04JWd6C0rQXCc8u5eMIdCfmEoSMzoamLUROd5AsS1errjLVCNjcSrCuJR7uO7fembW2tHu/4IyAkmUzgaw7allb6aewzm1u2VdJePryi8m7zP2hQMK4/82QPfFSntLlTJh1rG7NtrejA58s2+1KcwgFbWM1NjkP1IkAIcwqV4Ui7s99flXKC2UVogRllTNmbawGUabCIiqslDjXHDXeBF2wElLWsPEq7JbGBB2nxaD/67DPHMltPyq5y/hocdTVHRDrNxwfMIkRj/xQDLxh3w67jaiS4wLlDXjkZrce9gsQTDArLhrFB/3jfjdQOlhQzJ8ZqBukgLYYG/Ah5UMXdhqxQUkUcW0hFU1fygXUcxkZVhDyz6o1r6UPOUs1MRbZFpEZpCwhDPBRGUgvymUMaMuaZubKAv4MpJnteHLIq8RZomG+k39h7FT15Qg==; 5:bLkvQJi4qrD0xSgGRYOKJFVtGQmlB9iCwTAGsOqZ2Gi2i+JD3DtAafdRlxQdK2iDkcYxUJiFl7q/qS+X0VUNSKuAQFyxie+cOApa3bIbDxTRH1zZd6lepFncDMEJ7YD5BVgmoKIb4aK0+nFhRUS+X7eVSHAWhAR1Tn1H+RDubpM=; 7:Kz2AdEPOilydjQHwhB1bI+g/s05baAd9tDFdIesZTa8xipQdwiCZYTZCYE37Df2DuGEi8rNZVBIQN1wQg87ORwOZG9RcaMw2walkG9CUZgZyU0BXLmVvg/Yd9axKh9OEA9uSWOQ8G1g7BLwbe/ZMBA== x-ms-office365-filtering-correlation-id: caa4540e-ba43-43ce-e409-08d63efb46e4 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)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:BYAPR07MB4230; BCL:0; PCL:0; RULEID:; SRVR:BYAPR07MB4230; x-forefront-prvs: 084285FC5C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916004)(346002)(39850400004)(396003)(366004)(376002)(136003)(13464003)(199004)(189003)(52116002)(446003)(93886005)(97736004)(1076002)(14444005)(102836004)(6116002)(186003)(6916009)(3846002)(11346002)(486006)(53936002)(71200400001)(6506007)(7736002)(256004)(66066001)(2900100001)(305945005)(99286004)(78486013)(26005)(476003)(5250100002)(386003)(71190400001)(33896004)(33716001)(42882007)(8676002)(25786009)(81156014)(81166006)(229853002)(316002)(33656002)(5660300001)(6246003)(8936002)(72206003)(2906002)(107886003)(6512007)(4326008)(14454004)(106356001)(9686003)(54906003)(68736007)(76176011)(105586002)(6436002)(478600001)(6486002); 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: AkQ4yfWOlWZxiShX8YErh7HdMOHuZxAVoPLoIKr394VxUVOo9vx/AR305lO8vm75DEpcBWEYrcCkfUegpi/HDw6EqFABtUSGCfqb6zgMM4bWPtTORgwqT+sjRaMlR2+x2XgMA2cARnMPP5XYOnv1n/1UhRcY5A1Vy6LwmkE0gjPv+uNjDL2HYj1RdB/qGjrFdeK8jFMrm8iu6yMChEfhKgHMISa0eOdeWGauXwG9rqJdvDd8ztMzG2hIGw3QBrDQJyHJFRpq0VLzKdB7s3k7nef9WFrRnvCTe+afuYOSc6hkuqyi7UeY9q8sJia/IiOK3LoVmi4kqHGU8U7C/9r6mbjWQc/4ZjpETHdA9uJcjPQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <20E8DA66848F71438A91CFF4E0FDA8A9@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-Network-Message-Id: caa4540e-ba43-43ce-e409-08d63efb46e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2018 06:37:06.9748 (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: Wed, 31 Oct 2018 06:37:08 -0000 -----Original Message----- > Date: Tue, 30 Oct 2018 13:53:30 +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, >=20 >=20 > > > > > > > + > > > > > > > +/** > > > > > > > + * Checks that inside given rte_ipsec_session crypto/securit= y fields > > > > > > > + * are filled correctly and setups function pointers based o= n these 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 op= s that 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 b= elong 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 co= de set 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[], u= int16_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, str= uct 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, stru= ct rte_mbuf *mb[],uint16_t num); > > > > > uint16_t (*event_process)( const struct rte_ipsec_session *ss, st= ruct rte_event *ev[],uint16_t num); > > > > > > > > > > Or we can keep one function pointer, but change it to accept just= array of pointers: > > > > > uint16_t (*process)( const struct rte_ipsec_session *ss, void *in= [],uint16_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 ch= eck > > > > by anonymous union of both functions > > > > > > > > RTE_STD_C11 > > > > union { > > > > uint16_t (*pkt_process)( const struct rte_ipsec_session *ss,s= truct rte_mbuf *mb[],uint16_t num); > > > > uint16_t (*event_process)( const struct rte_ipsec_session *ss= , struct rte_event *ev[],uint16_t num); > > > > }; > > > > > > > > > > Yes, it is definitely possible, but then we still need 2 API function= s, > > > Depending on input type, i.e: > > > > > > static inline uint16_t __rte_experimental > > > rte_ipsec_event_process(const struct rte_ipsec_session *ss, struct rt= e_event *ev[], uint16_t num) > > > { > > > return ss->func.event_process(ss, ev, num); > > > } > > > > > > 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); > > > } > > > > > > While if we'll have void *[], we can have just one function for both = cases: > > > > > > static inline uint16_t __rte_experimental > > > rte_ipsec_process(const struct rte_ipsec_session *ss, void *in[], uin= t16_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 > Ok, let's keep them separate, NP with that. > I'll rename ipsec_(prepare|process) to ipsec_pkt_(prepare_process), > so you guys can add '_event_' functions later. OK > Konstantin >=20