From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0071.outbound.protection.outlook.com [104.47.36.71]) by dpdk.org (Postfix) with ESMTP id A27A2107A for ; Wed, 13 Dec 2017 13:28:33 +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; bh=x+Rxz0NNHU+Lgz8c4/k4RpFLokLuU93UtKnD9CP96Cc=; b=jQGWQBnOYwB5gEBpT9HmRTC/76BVd09yp8E1iwf4HMDbH6/htPv2E63h2pFVZzASuaxuhGt/U70NeP8J0rXVFL/uEaRr0LoANJm3RGYhftnxMLPvmgxEnAOj37CA6TLZixsXa4IDmUeIv2Ya7ovmdufF/SzigunUGV860TemTN8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Nithin.Dabilpuram@cavium.com; Received: from [10.90.205.104] (115.113.156.2) by CY1PR07MB1512.namprd07.prod.outlook.com (10.161.168.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Wed, 13 Dec 2017 12:28:28 +0000 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, narayanaprasad.athreya@cavium.com References: <1510210453-61428-1-git-send-email-abhinandan.gujjar@intel.com> <20171129114153.GA16467@jerin> <20171213112606.GA5166@jerin> From: Nithin Dabilpuram Message-ID: <780d2af1-88e7-196c-eec8-bb10b74d1563@cavium.com> Date: Wed, 13 Dec 2017 17:58:22 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171213112606.GA5166@jerin> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [115.113.156.2] X-ClientProxiedBy: CO2PR06CA0068.namprd06.prod.outlook.com (10.165.93.26) To CY1PR07MB1512.namprd07.prod.outlook.com (10.161.168.140) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7cf9d578-ee8a-4b04-43ed-08d542250591 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(7168020)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307); SRVR:CY1PR07MB1512; X-Microsoft-Exchange-Diagnostics: 1; CY1PR07MB1512; 3:Pscc1nIFWz6pKMy7kWZB1CcPdnAXTWYGR9JzjmSIQZ1FRjfhV/uyjzJEP37k0W9dLdjIUrfmHkB8UdSUOH7org+CiaVqnbD0sxObPOHL+RKlMs3xjHuUuhLaxFqsLjqcORFd3KU5VGjr4iH+xNBGZj41WwVJbB3OJBo3pefCTMC6fs0h8p3iFtqjWo4a9fNfTGVdTgkjTE/iMpABucgk2GvA46dvXZEq7w4QzlB6HWgyQqOnBXmRZrRw0vNRx9Ef; 25:2mBMy2Aza3TjQwtbEMxwVIARcGL3h2n+W4jODazOvPypxPxDtkgWznchyeVbk/hVeafM/nnazZFsmDj/r6FnftHpNRGn5moQhxCoRD2vxLHlHYAwFLAltYong2tGI3z6nhVAZA4a3RnIwT/PoKwY9IdLPL1FNYEU9GcLKd+ijjyPiGJcP4L6ruqI644teemYUV1ivIjwH9ISpB3kuqF2NEO1BXedDw4FWdt4hnsXcJ6PLBAf8jwgFZ7pH1JOJtsnm6T5lR6GPbc8QeHmUQSeP8WtGHVT3ccyv3xx8s72TQ/5aKOzYsU6fbxlyzLQPd1uMneNZi3+4v6Xfzx2j5z/+x/ZaJmACaH/ySz/Nx1Nl1A=; 31:rh3K6Fp8PiQfeQTuKA6UN+YJN8XevOB686GOKyWGZ7SEySGlc/SDYs3WudniSIFmZyOp+PHJCN5nQWkmZ441UiRRStF2up+e2FRrnkhWE33SHXd4haKzkTJZyqxXJP89RfFzY8wGTdv3jba//sNgRMdkZbi27TDEXsQfj51lrEz8NvFxW3JTSoiuM+lYN8c5bBR2CHbAPmo9dVe06a05jlcfHoayTVjAyDo871JcpSQ= X-MS-TrafficTypeDiagnostic: CY1PR07MB1512: X-Microsoft-Exchange-Diagnostics: 1; CY1PR07MB1512; 20:zqGzZ95qHEWeSBeFb5sCJsoIVsHjac0m2fT5w7sNkd3vw84BxGL+6XT4Mq6Q3iJKfZzuAiAmMkfDtNVPgxjCEtMR3/rgTyWYfQQpkveq1qvKyq/3W6+pXQw+emTTY5/7UVvVyY9QsWYzrVVdc+0exRw8TZfHvT4jECdg4nPzaTzt8o71ulaxYpa15waJ1nIlCx5SdNjcF58/KgVYrTLXR/a434K4aDlIyLw6RSmp2r0FSnprl4PapK7YqtpQ0Dq+3DihrKOWsm65/1x5n+OiQW4Ff2PxFtXVcP295hUJPX7AXibGNl7vV/RfA1JnFe5VOuAErx5JsRnqWZOjZ4s6x+xc/gT6opuJqiV6Q2gohPFFwhQxuPLTTu8zE28XlBXTDqYwFCd7TFYQA3klyefO+YOdQx6IZPbF3/FC9K+qkkYaJsWFY7yhiJsv6JxlRKIBUQ/4Uv3OwMkN+9Q3MJKMGqrapTrMWrl9rldh12mca//QLfOFeo8x9HexMu9USpej; 4:02m9L3PO6EzY+lHWjaHSSgPedRa0ac/iZ6v4KHGNnF0UA0NZMS/dflxath8ute/fCmAA2PKZfNRC8OExHmxlNNkUR3ubIYNFumjvhohXeJ1EKVVh+CQRza4PZg4nxHjKus6G+nVTHzPia5ojI0bl75hmQAglLePOSyxjl4hOhGX9jSs5+yd53VbukypVRHQ8sRSsgxlRuhofqgFt4ATg/L9Gb2fac35sEQpJziRqYIZP0R7toblWhPXViKdPwV8CdkDf7Zsi+UY823X60bG2exmf6xb4tRQjQIEBYjGFVdVnygNJ38ggr1OgNtkSeV7Kds4lyr28BMcBTTHS/4C6bgkrTbBa0Q9niclt5uqCtTnTyir0ST3SNFughhKiGOuz X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(185117386973197)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(3231023)(10201501046)(93006095)(93001095)(6041248)(20161123555025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148)(201708071742011); SRVR:CY1PR07MB1512; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY1PR07MB1512; X-Forefront-PRVS: 052017CAF1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(366004)(346002)(376002)(13464003)(189003)(199004)(24454002)(90366009)(25786009)(52146003)(83506002)(53936002)(93886005)(2906002)(23676004)(68736007)(110136005)(2486003)(97736004)(8676002)(58126008)(59450400001)(8936002)(52116002)(31686004)(6486002)(55236003)(229853002)(16526018)(77096006)(478600001)(16576012)(66066001)(31696002)(86362001)(8656006)(5890100001)(65806001)(76176011)(6666003)(2870700001)(47776003)(2950100002)(3846002)(6116002)(36756003)(67846002)(105586002)(65956001)(5660300001)(72206003)(316002)(64126003)(81166006)(106356001)(4326008)(107886003)(7736002)(81156014)(305945005)(54906003)(65826007)(386003)(50466002)(6246003)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR07MB1512; H:[10.90.205.104]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA3TUIxNTEyOzIzOmV0YkpsSVp0ZzFUOW5MZllTVSt6Z1FKUHkz?= =?utf-8?B?ODRqRG9xdTBQSVNPWUdDdFpiUVJsRXhiTHJ2Tm1YSk5pbm5jM09rSFhZbEY1?= =?utf-8?B?TFRzYTNjeSt1U05zU1QybnluUUx2RURBYjM0bkpBSEZmaG0zM3FQcU9DWEtu?= =?utf-8?B?OUY3UjBPUm4vazQ5b3BwUXdKWEdDZDNsbEJlYXAvejI5cmVIMUNMWVNZdlQ3?= =?utf-8?B?cUhQWWdRUEZpSnd0VE9FS3Fyd0xUSkprS3pWQUJ0ckZBWnJwOFd1TE1LTll0?= =?utf-8?B?ek1VWEtSd01KUWpjSCttRG93Q05oVjZpUlZYNmptU052VjRTMlFGV2R1QWZa?= =?utf-8?B?MEd5S2VqZkFUUTVxTkFkaFZNK01HdkR1bGhJRjQ3bWg0cDJyRS9uR3dRWTZH?= =?utf-8?B?R1FFbDBRbWhUYXFWdVlaWlFTOEI3ZUduR1Avb2hlMG4yVDZ0bWZmMW9BVDhk?= =?utf-8?B?TmVVY0tvMkY1bjdHNFhDM1lOeFNZZXZSbEFQdXFOaGw2VDFPWnVqMVRGS0xw?= =?utf-8?B?Unl0QXdBRnZ3cm8zbEJmL3pxcTdJWUtlM2diRXZGMFNVQ1JHcFFTQ1dFci9D?= =?utf-8?B?ZHhoVGxMbXRXQ0FUa3JGMzZNZDM0R0s4SWlyTXZSUnF1TWlLZU9PdWY1TC9C?= =?utf-8?B?ZGYyUlN2UUFuMk5PNm1KdzVCcjNvVVYraDU4Ym9QWXRRUnVtU2hwRDlaOXRP?= =?utf-8?B?L3Rxd1lhSXhRYjdsa2U1Y0VUTFJoT3pLc2xURllkZ1NBa0drVDBoLzEyN2RF?= =?utf-8?B?NVV6TVU3akxwcTl5K3RzTEV3Vmc0VjhtVkVJdjNIeUJlUTlncFF1R3VjL1pW?= =?utf-8?B?VnVZUjhqUzkvcGQydUQxV0JFZVhRNWNvVXVFTVFGZXQwQnlUZGRiUGJXelJK?= =?utf-8?B?dWV5SjdhQUdCYWZwR3J2blNjQjFOeHA5RGROd1Eza2FLYURpYmVURkVWUlYy?= =?utf-8?B?ZHhzeU1nMSttQUNBYjk4eEI3eVhDVnNxWDZiL29NTTloaEQvL1IxdkZLb09u?= =?utf-8?B?VW9UNWJVdytjV3BmbnhUOTdxSWE0b2JMMTM5SkVJR3J1T2pjZkNDQWs5SlNZ?= =?utf-8?B?WnV2MFZ6N3VkbTQwbHAyMFdkUXhVZEpPM2JNSVNaQlE0Wkg5YzBuTGZoT00y?= =?utf-8?B?eTQwM29aaitVR3RVRUtjcG9yT1ZDWC9MaG9zRHZEYmd5S09TNmtkMHd4MDdJ?= =?utf-8?B?dXFNTVNRR2h4OGhyOHFrSlpjai9jV3R3SFB5K0NKeTFlTVFUajVNSzdHMWhF?= =?utf-8?B?L1dQdHIyOXZCTFB6Tm1CYXJwRDJMdTF3VkxIQTl0ZkpQNFp6N3BPUUI2aVZm?= =?utf-8?B?NlFjN3BSZmt2L0llM0VhU3Zzem9OUjUveGxqR1BhdzA5QkdReGdmdVNTNmsy?= =?utf-8?B?eUp3QjdzS2lncWxiQjlMMnpITXNjeXhuaStONmZqVE12bXhHanAxOTMzTDRZ?= =?utf-8?B?UU5tMDcyZ2twb0E2RVo1VkFMeWhpOGRFQ3hONUFQeC9kRmNjQjJqM05aVWJn?= =?utf-8?B?MUtXWXRmUlowajV2QkkrUUN1TGxzQU1pNXJhckhZZzQ2aHB3RUpob2JVVm92?= =?utf-8?B?WTJNbUNEZmhUc3ZWMTZMV2JMdE5Hc3ZBRmNrUUZRc0h1amJWeG56V0pNZHdP?= =?utf-8?B?NE5tUklVOFZNazNoSVV3b2lyZEVqbFpZa0lLY3h0SjgvU1N2NzllbnpHNFRQ?= =?utf-8?B?Y1UvWXU2ZmpObUFNWnlNV2NzNEt1OFhlQThUUkljcllnek16NzZ2Um53U1Zk?= =?utf-8?B?aUd1Wk9GeEtoSy9oc0VxSTZYK2VHczh0SHhNdnBZRjYyWHVnYUhyVzRmUUhy?= =?utf-8?B?VVFkRE5qbUtySGw4K0poMFNXVFZCY1RkeSs3dThtdUhDQmNOQXdjbzJlREEv?= =?utf-8?B?WDRvbzdSNGpVWWhBZE5iWU1aVXdUWjAyL3FTMUt4SHJGUHkyaVNtS0pPYTdM?= =?utf-8?B?a2grUXRTcHYrM3NQU2dvcko2MGpxVjdVbnA0NmRRWUo1MzhIU054UUt6MEVs?= =?utf-8?B?V3lOMXlMU1Y4MkMvUGpYQU14WTc5WXhLOFBpSnZ2dFBuYkR0cTJyT1hJNmdx?= =?utf-8?Q?Aoa5I4HVCVQ5xJhUOXYFMzYhW?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR07MB1512; 6:CPc/EnDYNcEjrivC1R5CiO9bAFtw2gPTcuG2O717JGJbnD11bNKBwX2JeKNDX9vBFr0b46gSFjCG5Kj01hwwp16YMjYK74Lc2K9KbmzZpgCm07HviPIs7L04gYl4kWXHHU75NGIxj8y99fyR+sBtkdyobwPradodAUfb7Hwf7LZH3kyCHrXIEc+7JOwxZEZPUO3xFdIq03zRqBPt/pShKPLXiZW1AGuujNCMD0cl3MVwZfvWkqKKE2bdRXcK10zsFGCGgax+/ZT/znt2gSbB2WmBkwI9LZX07Rg5Wi3Qm0/fZpFo0uz2pCG/j3mgY2pa6SJAurrpAYGSV4DVo2DeiBLDc9A+8ZinvuIsZigh1k8=; 5:+xVRTm+LXQOz0pxR57+hOeRhIInN/wMF+TJ98wNVX9T08hYcFOjPhIa03QJ1AqBOkj6QB6d+idFwjaKyzWqmLtFNDTOfV/xaM1JwJnz2PI8iIaShWeUmPQcHhFbQYWcl04slAxtGv/DCaqGbcW5vHBgiiujvdZn8Mqfj8pDAdrE=; 24:NVV43PzUd8WctAcQxf8VhYi98wzqLcGr5Q8/sje6kX9oWvvP4YdnK64KtD1Lica8RLCUpBs2QbMpY//QebUvruoCiTpyVyC9+bv0LYeaRH8=; 7:xKrBbNe5PUfPdNQeK8w40UwTAEEZaaY8wW7KevAmDrVr8HhAo4SEiw6CiIUuyQdGmWpDLvfE6FpmInQstLf6e4Pt8kiEoTCguu9ma3+Fofef3hSGTxdnpnS1QZEBSCiSCxGHae2fhxr1TRSeuFF1PsrkvUC/YZ2bs+19SFbzXfFlCGAnDPS9crDkSpCZipt89SrSd9Ua3xNIDXqlPaESvZQCr7CZ1h/H7apY3vruySbzEvIX0x+NgZu0ATTFypO9 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: cavium.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Dec 2017 12:28:28.6484 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7cf9d578-ee8a-4b04-43ed-08d542250591 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR07MB1512 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: Wed, 13 Dec 2017 12:28:34 -0000 Hi Jerin, Declan, On Wednesday 13 December 2017 04: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? Can we have this info in structure rte_crypto_sym_xform instead of rte_crypto_op so that for session less or session full we have just one api say as below to update the event information. rte_cryptodev_sym_xform_event_init(struct rte_crypto_sym_xform *xforms,                                                             struct rte_event ev) IMO, this is better because for both session_less or session_full modes, app has to prepare sym_xform structure and in case of session_less make the struct rte_crypto_op point to sym_xform and in session_full pass it to rte_cryptodev_sym_session_create(). The same can be followed for asym/security sessions in future if needed. >>> ➜ [master][dpdk.org] $ git diff >>> diff --git a/lib/librte_cryptodev/rte_crypto.h >>> b/lib/librte_cryptodev/rte_crypto.h >>> index 3d672fe7d..b44ef673b 100644 >>> --- a/lib/librte_cryptodev/rte_crypto.h >>> +++ b/lib/librte_cryptodev/rte_crypto.h >>> @@ -115,6 +115,9 @@ struct rte_crypto_op { >>> uint8_t reserved[5]; >>> /**< Reserved bytes to fill 64 bits for future additions */ >>> >>> +#if 0 >>> + Crypto completion event attribute. For _session less_ crypto enqueue operation, >>> + The will field shall be used by application to post the crypto completion event >>> + upon the crypto enqueue operation complete. >>> >>> + Note: In the case of session based crypto operation, SW based crypto adapter can use >>> + this memory to store crypto event completion attributes from the PMD >>> + specific session area. >>> + >>> + Note: ev.event_ptr will point to struct rte_crypto_op *op, So >>> + that core can free the ops memory on event_dequeue(). >>> +#endif >>> + >>> + struct rte_event ev; >>> >>> struct rte_mempool *mempool; >>> /**< crypto operation mempool which operation is allocated from >>> * */ >>> diff --git a/lib/librte_cryptodev/rte_cryptodev.h >>> b/lib/librte_cryptodev/rte_cryptodev.h >>> index dade5548f..540b29e66 100644 >>> --- a/lib/librte_cryptodev/rte_cryptodev.h >>> +++ b/lib/librte_cryptodev/rte_cryptodev.h >>> @@ -945,6 +945,13 @@ rte_cryptodev_sym_session_init(uint8_t dev_id, >>> struct rte_crypto_sym_xform *xforms, >>> struct rte_mempool *mempool); >>> >>> +#if 0 >>> + Create PMD specific session meta data for the destination event queue >>> + attribute to post the crypto completion event on crypto work complete. >>> +#endif >>> +int >>> +rte_cryptodev_sym_session_event_init(uint8_t dev_id, >>> + struct rte_cryptodev_sym_session *sess, >>> + struct rte_crypto_sym_xform *xforms, >>> + struct rte_mempool *mempool, >>> + struct rte_event ev); >>> + >>> /** >>> * Frees private data for the device id, based on its device type, >>> * returning it to its mempool. >>> >>> >>>> + * >>>> + * The metadata offset is used to configure the location of the >>>> + * rte_event_crypto_metadata structure within the mbuf's private metadata area. >>>> + * >>>> + * When the application sends crypto operations to the adapter, >>>> + * the crypto queue pair identifier needs to be specified, similarly eventdev >>>> + * parameters such as the flow id, scheduling type etc are needed by the >>>> + * adapter when it enqueues mbufs from completed crypto operations to eventdev. >>>> + */ >>>> + >>>> +#ifdef __cplusplus >>>> +extern "C" { >>>> +#endif >>>> + >>>> +#include >>>> +#include >>>> + >>>> +#include "rte_eventdev.h" >>>> + >>>> +#define RTE_EVENT_CRYPTO_ADAPTER_MAX_INSTANCE 32 >>>> + >>>> + /** >>>> + * @warning >>>> + * @b EXPERIMENTAL: this enum may change without prior notice >>>> + * >>>> + * Crypto event queue conf type >>>> + */ >>>> +enum rte_event_crypto_conf_type { >>>> + RTE_EVENT_CRYPTO_CONF_TYPE_EVENT = 1, >>>> + /**< Refer RTE_EVENT_CRYPTO_ADAPTER_CAP_MULTI_EVENTQ */ >>>> + RTE_EVENT_CRYPTO_CONF_TYPE_MBUF, >>>> + /**< Refer RTE_EVENT_CRYPTO_ADAPTER_CAP_MBUF_MULTI_EVENTQ */ >>>> + RTE_EVENT_CRYPTO_CONF_TYPE_MAX >>>> +}; >>> See above. >>> >>>> + >>>> + /** >>>> + * @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? >>>