From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 912539FE for ; Thu, 14 Dec 2017 19:53:37 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2017 10:53:33 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,401,1508828400"; d="scan'208";a="2864576" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga006.jf.intel.com with ESMTP; 14 Dec 2017 10:53:33 -0800 Received: from fmsmsx115.amr.corp.intel.com (10.18.116.19) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 14 Dec 2017 10:52:03 -0800 Received: from fmsmsx108.amr.corp.intel.com ([169.254.9.23]) by fmsmsx115.amr.corp.intel.com ([169.254.4.132]) with mapi id 14.03.0319.002; Thu, 14 Dec 2017 10:52:02 -0800 From: "Eads, Gage" To: Jerin Jacob CC: "Gujjar, Abhinandan S" , "dev@dpdk.org" , "Vangati, Narender" , "Rao, Nikhil" , "hemant.agrawal@nxp.com" , "Doherty, Declan" , "nidadavolu.murthy@cavium.com" , "nithin.dabilpuram@cavium.com" , "narayanaprasad.athreya@cavium.com" Thread-Topic: [RFC] eventdev: add crypto adapter API header Thread-Index: AQHTWSeZpnLyvUOAk06zOraV312JvqMr4eoAgBY5GKCAAMUIgIAAfusg Date: Thu, 14 Dec 2017 18:52:02 +0000 Message-ID: <9184057F7FC11744A2107296B6B8EB1E2BB1B9FF@FMSMSX108.amr.corp.intel.com> References: <1510210453-61428-1-git-send-email-abhinandan.gujjar@intel.com> <20171129114153.GA16467@jerin> <9184057F7FC11744A2107296B6B8EB1E2BB1B296@FMSMSX108.amr.corp.intel.com> <20171214024910.GA10018@jerin> In-Reply-To: <20171214024910.GA10018@jerin> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjY4MDQwNjItY2NiZi00N2E2LWJkYzUtZGM5ZmIyYzU2MDcwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6Ink4ZGlmRE4xQUhnbDJqNlFUckpwQ2ZucEFMdWVRMTBQeG02Y1c4YzFiSkU9In0= x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.1.200.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC] eventdev: add crypto adapter API header 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, 14 Dec 2017 18:53:38 -0000 > -----Original Message----- > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > Sent: Wednesday, December 13, 2017 8:49 PM > To: Eads, Gage > Cc: Gujjar, Abhinandan S ; dev@dpdk.org; > Vangati, Narender ; Rao, Nikhil > ; hemant.agrawal@nxp.com; Doherty, Declan > ; nidadavolu.murthy@cavium.com; > nithin.dabilpuram@cavium.com; narayanaprasad.athreya@cavium.com > Subject: Re: [RFC] eventdev: add crypto adapter API header >=20 > -----Original Message----- > > Date: Wed, 13 Dec 2017 23:35:48 +0000 > > From: "Eads, Gage" > > To: Jerin Jacob , "Gujjar, Abhinandan S= " > > > > CC: "dev@dpdk.org" , "Vangati, Narender" > > , "Rao, Nikhil" , > > "hemant.agrawal@nxp.com" , "Doherty, Declan" > > , "nidadavolu.murthy@cavium.com" > > , "nithin.dabilpuram@cavium.com" > > , "narayanaprasad.athreya@cavium.com" > > > > Subject: RE: [RFC] eventdev: add crypto adapter API header > > > > Hey Jerin, >=20 > Hey Gage, >=20 > > > > > > > > > > + > > > > + /** > > > > + * @warning > > > > + * @b EXPERIMENTAL: this enum may change without prior notice > > > > + * > > > > + * Crypto event adapter type > > > > + */ > > > > +enum rte_event_crypto_adapter_type { > > > > + RTE_EVENT_CRYPTO_ADAPTER_RX_ONLY =3D 1, > > > > + /**< Start only Rx part of crypto adapter. > > > > + * Packets dequeued from cryptodev are new to eventdev and > > > > + * events will be treated as RTE_EVENT_OP_NEW */ > > > > + RTE_EVENT_CRYPTO_ADAPTER_RX_TX, > > > > + /**< Start both Rx & Tx part of crypto adapter. > > > > + * Packet's event context will be retained and > > > > + * event will be treated as RTE_EVENT_OP_FORWARD */ }; > > > > > > How about leveraging ev.op based schematics as mentioned above? > > > > That could work, but perhaps the ev.op should be configured once up fro= nt, as > I see it being a function of the application architecture. A couple possi= ble > designs, for example: > > - Worker enqueues into cryptodev, adapter polls for response: the adapt= er > port would always use OP_NEW here. > > - Worker sends a crypto request event to the adapter, which gives the > > request to the cryptodev and polls for response: the adapter port > > would always use OP_FWD here. (This ties in with my implicit release > > patch (http://dpdk.org/ml/archives/dev/2017-December/083535.html)) > > - Etc. >=20 > Yes. Semantically both approaches will work. I was trying to avoid extra > clutter(enum rte_event_crypto_adapter_type) in adapter API. > I don't see any problem in moving ev.op to adapter configuration time if = it helps > the SW driver. >=20 > IMO, We can change RTE_EVENT_CRYPTO_ADAPTER_RX_ONLY and > RTE_EVENT_CRYPTO_ADAPTER_RX_TX to more appropriate name, something > like, > RTE_EVENT_CRYPTO_ADAPTER_TYPE_OP_NEW/RTE_EVENT_CRYPTO_ADAPTE > R_TYPE_OP_FWD > or something like that. >=20 I agree that the two naming schemes are equivalent, but since this option w= ould control the adapter's behavior (Rx only vs. Rx + Tx), (IMO) I think Ab= hinandan's original names do a better job of conveying what effect these tw= o options have on the adapter, compared to the op type names. >=20 > > > > So I think it makes sense to specify the op once at adapter configurati= on time, > rather than repeatedly in the datapath. This allows for a cleaner separat= ion of > configuration and datapath code, and specifying it just once means fewer > chances to accidentally set the wrong op value. > > > > Thanks, > > Gage