From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [RFC] eventdev: add crypto adapter API header Date: Wed, 13 Dec 2017 23:07:53 +0530 Message-ID: <20171213173752.GB3462@jerin> References: <1510210453-61428-1-git-send-email-abhinandan.gujjar@intel.com> <20171129114153.GA16467@jerin> <20171213112606.GA5166@jerin> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Doherty, Declan" , Abhinandan Gujjar , dev@dpdk.org, narender.vangati@intel.com, Nikhil Rao , Gage Eads , hemant.agrawal@nxp.com, nidadavolu.murthy@cavium.com, nithin.dabilpuram@cavium.com, narayanaprasad.athreya@cavium.com To: Akhil Goyal Return-path: Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0053.outbound.protection.outlook.com [104.47.33.53]) by dpdk.org (Postfix) with ESMTP id AC56B107A for ; Wed, 13 Dec 2017 18:38:18 +0100 (CET) Content-Disposition: inline In-Reply-To: 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 19:52:24 +0530 > From: Akhil Goyal > To: Jerin Jacob , "Doherty, Declan" > > CC: Abhinandan Gujjar , dev@dpdk.org, > narender.vangati@intel.com, Nikhil Rao , Gage Eads > , hemant.agrawal@nxp.com, > nidadavolu.murthy@cavium.com, nithin.dabilpuram@cavium.com, > narayanaprasad.athreya@cavium.com > Subject: Re: [RFC] eventdev: add crypto adapter API header > User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 > Thunderbird/52.5.0 > > Hi Jerin, Hi Akhil, > On 12/13/2017 4:56 PM, Jerin Jacob wrote: > > -----Original Message----- > > > Date: Wed, 13 Dec 2017 11:03:06 +0000 > > > From: "Doherty, Declan" > > > To: Jerin Jacob , Abhinandan Gujjar > > > > > > CC: dev@dpdk.org, narender.vangati@intel.com, Nikhil Rao > > > , Gage Eads , > > > hemant.agrawal@nxp.com, nidadavolu.murthy@cavium.com, > > > nithin.dabilpuram@cavium.com, narayanaprasad.athreya@cavium.com > > > Subject: Re: [RFC] eventdev: add crypto adapter API header > > > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 > > > Thunderbird/52.5.0 > > > > > > On 29/11/2017 11:41 AM, Jerin Jacob wrote: > > > > -----Original Message----- > > > > > > ... > > > > > > > > > > > Adding Declan and Hemant. > > > > > IMO, RTE_EVENT_CRYPTO_ENQ_MULTI_EVENTQ may not be very useful > > > > from application perceptive as the scope is very limited. > > > > In real world use cases, we will be attaching destination event queue information > > > > to the session, not to the queue pair. > > > > > > > > > > > > IMO, RTE_EVENT_CRYPTO_ENQ_MBUF_MULTI_EVENTQ scheme may not very > > > > convenient for application writers as > > > > # it relies on mbuf private area memory. So it has additional memory alloc/free > > > > requirements. > > > > # additional overhead for application/PMD to write/read the event queue metadata > > > > information per packet. > > > > > > > > Since we already have meta data structure in the crypto > > > > area, How about adding the destination event queue attributes > > > > in the PMD crypto session area and for, _session less_, we can add it > > > > in rte_crypto_op stricture? This will help in: > > > > > > > > # Offloading HW specific meta data generation for event queue attributes > > > > to slow path. > > > > # From the application perspective, most likely the event queue parameters > > > > will be different for each session not per packet nor per event queue > > > > pair. > > > > > > > > > > Hey Jerin, > > > > Hey Declan, > > > > > > > > given my limited experience with eventdev, your proposed approach in general > > > makes sense to me, in that a packet flow having crypto processing done will > > > always be forwarded the same next stage event queue. So storing this state > > > in the crypto session, or crypto op in the case of sessionless ops, seems > > > sensible. > > > > > > > Something like below to share my view. Exact details may be we can work it out. > > > > > > > > > > I terms of your proposed changes below, my main concern would be introducing > > > dependencies on the eventdev library into cryptodev, as with this new crypto > > > adpater you will have a dependency on cryptodev in eventdev. > > > > I agree with your dependency concern. > > > > > > > > I think the best approach would be to support opaque metadata in both the > > > crypto op and crypto session structures, as this would allow other uses > > > cases to be supported which aren't specific to eventdev to also store > > > metadata across cryptodev processing. > > > > Make sense. Just to add, adding a pointer would be overhead. I think, we > > can reserve a few bytes as byte array and then later typecast with > > eventdev api in eventdev library. > > > > uint8_t eventdev_metadata[SOMEBYTES]; > > > > Thoughts? > I believe only 1 uint64 is sufficient. The metadata that we need here is > rte_event which is 2 uint64 and the second one is mbuf. Since mbuf is > already part of rte_crypto_sym_op, we do not need it. Yes. > > So only a pointer/uint64 is required. I would say uint64_t, as the pointer is 32bit in 32bit systems.IMO, We need have reserved metadata(uint64_t) for eventdev(not generic).