From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [RFC] eventdev: add crypto adapter API header Date: Thu, 14 Dec 2017 08:19:11 +0530 Message-ID: <20171214024910.GA10018@jerin> References: <1510210453-61428-1-git-send-email-abhinandan.gujjar@intel.com> <20171129114153.GA16467@jerin> <9184057F7FC11744A2107296B6B8EB1E2BB1B296@FMSMSX108.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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" To: "Eads, Gage" Return-path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0079.outbound.protection.outlook.com [104.47.40.79]) by dpdk.org (Postfix) with ESMTP id 3DF921B00B for ; Thu, 14 Dec 2017 03:49:32 +0100 (CET) Content-Disposition: inline In-Reply-To: <9184057F7FC11744A2107296B6B8EB1E2BB1B296@FMSMSX108.amr.corp.intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" -----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, Hey Gage, > > > > > > + > > > + /** > > > + * @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 = 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 front, as I see it being a function of the application architecture. A couple possible designs, for example: > - Worker enqueues into cryptodev, adapter polls for response: the adapter 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. 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. 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_ADAPTER_TYPE_OP_FWD or something like that. > > So I think it makes sense to specify the op once at adapter configuration time, rather than repeatedly in the datapath. This allows for a cleaner separation of configuration and datapath code, and specifying it just once means fewer chances to accidentally set the wrong op value. > > Thanks, > Gage