From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0053.outbound.protection.outlook.com [104.47.32.53]) by dpdk.org (Postfix) with ESMTP id 4617CD14E for ; Fri, 20 Apr 2018 15:15:08 +0200 (CEST) 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=VpNAa8fEMbx7ZQ2AmuEhs2WnNMkuK6J1w3oqcQPEpNc=; b=C7C8Kx93LyXbVnncxgq8cGciVv9W5jgtTxnIn6mDzrg+PWvrRZoe/YjWhH2bFdtPB6Tp9vd3ZAkRdWhH+m62IlXnxA3OMNrANBcOoXdJnWiQvqcwVPKPw+cTiLVAumNokumq+IRP1VT6rdA9H+o7/uQAdMV/MarZ42yhc/WBrb8= Authentication-Results: nxp.com; dkim=none (message not signed) header.d=none; nxp.com; dmarc=none action=none header.from=caviumnetworks.com; Received: from jerin (106.208.140.15) by BN3PR07MB2513.namprd07.prod.outlook.com (2a01:111:e400:7bbf::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.13; Fri, 20 Apr 2018 13:15:02 +0000 Date: Fri, 20 Apr 2018 18:44:46 +0530 From: Jerin Jacob To: Akhil Goyal Cc: "Gujjar, Abhinandan S" , "hemant.agrawal@nxp.com" , "dev@dpdk.org" , "De Lara Guarch, Pablo" , "Doherty, Declan" , "Vangati, Narender" , "Rao, Nikhil" , "Eads, Gage" Message-ID: <20180420131438.GA15553@jerin> References: <1522824999-61614-1-git-send-email-abhinandan.gujjar@intel.com> <5ea61576-9124-266a-00e6-cb9f22a37f59@nxp.com> <5612CB344B05EE4F95FC5B729939F780706E5DA8@PGSMSX102.gar.corp.intel.com> <37505d55-bdc3-78fb-009b-b38ba1cdbe66@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37505d55-bdc3-78fb-009b-b38ba1cdbe66@nxp.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Originating-IP: [106.208.140.15] X-ClientProxiedBy: MA1PR0101CA0004.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:21::14) To BN3PR07MB2513.namprd07.prod.outlook.com (2a01:111:e400:7bbf::10) X-MS-PublicTrafficType: Email X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN3PR07MB2513; X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2513; 3:Nnanojpc0SzN552gkcloj7amxyNLkxVMXYSafQARYDtAVatUJTlqDViY7rs1v4JIO7mS/g1ShR8Fcwsgi0gYW+HlqkuoD0ifRcECENAhENRAQ+IXiiqGHpVKHMdspxsVzfo3cWFX4rixg+1KoPyeLWXwf1WaLxLIUXZlq/GkZyuyLXTxk30bRQCPgBi88bvZ4e7MRNT5p60L8RJdhV3R+LdoxIdtzpkigVf9UzsmTCfWcB7Ud9CGpz1eU6yHRyoH; 25:jKWpZ1Z0enKQkur0AKNx5E17mddbD/eoiFDz9SaSNGFFxB/egj1aSdYg4P4WYISAutVH5PXCsuLaFCcikuKCxX6CUxcj0tfVkTVwfFLAc/5s4oZ4DvEj4LqID2S5TfFplQVpPbwIzagPAn/ApyDcm8aloo53E18xLRf3TcE6xI2UF+zRdUzG9+luQgZ7wJ/d/vYBOcvhkQnfl4YOMsVHPw8QU4I/v4EhC2wiFsRxJsQ/AiOUJ2wL5I7Yenwoks7M7V/Jvf/pOhav04QiUMjugil+X5EL+9M3p5DGXiV6Teu7zIG8JgN/vTEXaNEfhoxJOPb+h7T3C0SafrbZWIUztQ==; 31:6uFE0Vjzzl7oRhURU5T432KjA7DgsHuVW2HzTdg7Bzswg5/ohz6Aih0wIFwKk7HVsg1VGOXylPz/uwDf8Pry0zhaSdHWTE9SLEled8vDT/5CohUh2amJe0GPq4lo56S/Kok1+k9qnLfVQPs25ci/KDAnf3b6bWECwyZ2BRfqZFpskIL89N8nyTS8sMCJjxb2NbfzrVDogn7evzgT3//zOSRn5yH8rwOSaopHJGJ+xMY= X-MS-TrafficTypeDiagnostic: BN3PR07MB2513: X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2513; 20:Swm8xR3+TPH69+T9avrWcWodqpijiYtSnYbKOaRRAHsMo/qOyabyTGlsPOt+TmJ7DCJUWwXE7IUOL2/pvm8FECMKA++Sq55SrYONpW4QLYBsTBAEh0KKczKkA6fLpAIdws6fCqGyh5BYcemkapOL4Q4f/s2BS2vXk2KYFiTKsCmsPhQ9BCBEZmny1NKf9DBNqIhApv4Sh8kl8xL5efNYAgKkZp5JfH7Dr/8XsUUFdVp+DJpqF3Th5r9UVViV9pwhM/9dcHXvS2PUP2pxJjvNaBC/QfVuy2IvCNQ0TQpEJ0sXyDa535QNw0kK/yqkAVOR/ljpFpOLHc/NxS12sg0a9o9SaA6G5RZnf7bmSAF4wB3ijWdJroawcMuuVngiCI0XxqwoTvzE5MxDCSTX0Trmzj23kCQjxNOsMFYP8ApVMWEMWesvPIKOL1Gb0G93qRX6V0bMmAtPo46z2MVAXr5GgCyXQX8xF/ZBgCYwAasr70aWwg++M3VBBDfyKeSBYlhW7QI6b3LobhM+oaHHhaXpOgePyzMhZw5sykxl5gYuvuhCWdGGx1j6NqznWtbcNQmqXG93bJOMVDNtxt4SNhiqirOuNBRh7lyGiNk08mD3QLU= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(185117386973197)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(3231232)(944501394)(52105095)(10201501046)(3002001)(6041310)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:BN3PR07MB2513; BCL:0; PCL:0; RULEID:; SRVR:BN3PR07MB2513; X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2513; 4:MDmrqH370L6YFa3m+5fsRLA8h6cTR6G9+YpHnF63I24QkcayVeSj+NqDNxKHvcZI5MmC9C8YPaZQdOG0zP5GpNjTYu8dxjr2Ry/9831Mwj8TLssEnwaze05GJ7VjJdWrulzIW8y7Vo6nWulouYkLFNJzbvZDYuwuvqqoZ2C8arAB2N18ga0Kup+Mg4rCxmtGz65bEFRj2GIyeWbtaS2fn02DNEGYdNPEQUIdyZ+mThnSNLpNyJMvKzNLlI8y3SANzMlncdmqfVXkkyXVUnwIGOXNRy7bGLTfgYxJjZ77YEAk0/Mf8HN4tJw+DbC7JeDgmBa2WRDoO1uG4t7/pu/eoI7K34XjwH8ixnp552O10Nc= X-Forefront-PRVS: 0648FCFFA8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(39860400002)(39380400002)(396003)(366004)(376002)(346002)(13464003)(26005)(53546011)(386003)(229853002)(6916009)(6666003)(47776003)(42882007)(44832011)(33896004)(4326008)(8676002)(7736002)(8936002)(478600001)(81166006)(33716001)(8656006)(72206003)(966005)(316002)(33656002)(476003)(54906003)(16586007)(6306002)(956004)(446003)(53376002)(11346002)(9686003)(25786009)(53936002)(5890100001)(93886005)(55016002)(76176011)(6116002)(3846002)(16526019)(186003)(1076002)(5660300001)(23726003)(66066001)(50466002)(52116002)(2906002)(6246003)(305945005)(6496006)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR07MB2513; H:jerin; FPR:; SPF:None; LANG:en; MLV:sfv; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR07MB2513; 23:cTEQtGWrO9XcZepIQcKsFcIA/Xfpvb7sFU8jYFDAa?= =?us-ascii?Q?mqNwO/y0G6E3eA7z3LRqYyyArGI8meuhjs/IZojEvC+brnE5T83tzYohU9St?= =?us-ascii?Q?CtNlApY4Y94t+DuOCyZdgKbATtWydnvRz3Y04QObUMFSickWSPUUyK81YZxs?= =?us-ascii?Q?OjKkTUNQ/p1uN21JtjYteGADxpQchrL8ATSSVFSwQbPhvYy9mBxXuk+cmz+g?= =?us-ascii?Q?aghm6bC6pcr0+vdcoPRefB8lE91v74n5slDcpKs9b/x97D2u2o9hlgOsaarQ?= =?us-ascii?Q?XOghjMXLVFrCJzD4B+ZKpZ7ejoV2uKh4y3vWXtJeNtseXfbHZ6eHnkGRNq+Q?= =?us-ascii?Q?aaPWkV7t1SonTvSXGasnwHpgIL+duirdtpVJ4MAEzG8UqW2toD+D7yqv7mCt?= =?us-ascii?Q?NSL4zReecDCmLPJxJIEnkkw0qOpsSGHDoShqjA0tj1mLNe1ulc15EfY0uwrY?= =?us-ascii?Q?1Wq+6KUj8Fg9P9zW6tF433qeaQVMGv7KEZ6fQl/+QPCpOZRx3JQcvMgdNENH?= =?us-ascii?Q?Mt3wjKnizgh7ZpLTdlcv/6QNJh/oj7Oj0F4uQVtktIHTdbVdjuq+NiEXbGgi?= =?us-ascii?Q?c8oigAdPSOvbQIRc2vUQQUI/SDMt6ClEL2GtvbTiak7TGI3UGhx0e0STSlW7?= =?us-ascii?Q?agM2GnIOYYQKmaFspJ4nhKOcTqlOVJ2Nn4JGjtVCzjw0cSp4RiDi1o0GZUmB?= =?us-ascii?Q?avp23WRt1N0hzjK8oPFEZVJy6B4e8JzbyfXBdX801JUWY96gusq9ZFbbVYCA?= =?us-ascii?Q?Z6pxOwrzhe3/LdnO5pCbHtvqZkfL76Et2VazxBD/zFpimA9AgBdYLCZL28UU?= =?us-ascii?Q?Svbod6KxeFEH8wt/b4o60N9V1zkW9sgyhSozVGWTFzLTU7Kci1tQD4N1RsLt?= =?us-ascii?Q?M9gxk1dE4H6zqIzBC3lfeytC9/yyCZyNZ9cOMD2XgZ4ylIuz9D/mtJcryANj?= =?us-ascii?Q?vTclDmHgWmmnoW5svidZnBRU1EOgRWPYWos1RmyAglHx4bClPFBNRwmI1vUE?= =?us-ascii?Q?5geluXZ4ZPhbg3/MFjKDZsSiVfpyZzmj6z4f+AyNUXuXi2rcO0qKesJ8DDRW?= =?us-ascii?Q?J+QEkHAfOKfaAPB6NCx3AcN/FZFrMecL2zENH+pB5nCBc7uZKom0Z4A09LPY?= =?us-ascii?Q?NYN0j6dJxjvabLktA3djkvFYP7Oj5oV2ZIftWVUquMcDlThmVbSWPi0kqLai?= =?us-ascii?Q?c+lWJVJ6Rp9r030aZRf5LcFhEJILfdtUQHD8YHOgluhEwxkCOuY4VuEYpPXW?= =?us-ascii?Q?WBx0TCsc7AQSC4CuQd8h8x1Qcr8FXpohhArsrGhs/ZMc0kOFrursgD3ovUQx?= =?us-ascii?Q?PSbJs96yk5UI+qfXPfyTP8=3D?= X-Microsoft-Antispam-Message-Info: JMN8i1YaXYBf3xB6g7zvSLRBFjC3YdR4dWYHwa4rlHHywdN1h+ypXQSrvqHLC+ASvSbOiXCypmfysloAJ33K/0EBNvSg2xqW+rye+7zpUuZsKfWdKEH6jtk5xPBPc4eFEL8x3JbW9yRmxLdpXn9SA7tAVMTXvlWwYFhurVNqVgh213RmSKOvWU4+Up3jcF8f X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2513; 6:4O/pF+DERgJ9kCypBwZ9EXnU9c6nu0/9+QxaWXV2ga8eWk/8P9gWnlgRmvcytMdDgjpOWURcGuI6oOfinNmTZkvn4P53InXSswn4hFnRSg3EoWWFoWcIAvUkOTJeTBz8bfTWsMNLpHBWFc81EAAHJUkuW9pgeDCsW8W33hsdl4D0pJB8/CXLUz5/5CiM96xKvQqjaMNW6RwkTlsajbS//5fv5kEwdg5cTcPeqVy3wc2pgANEcMume9QEoDesIPN2UcXAJoupetXUrN2MYdRuIEmVRQZWWmA2AX9JnBv8+sdVy/grW+AefYyTtHHQbd4xFhZnOJSFcrrpB/kPs+U27DS5cQY+ChmvPmPRSiIAtpnUByIgmV1P/qJuRLBts4FEOklYcZU6mtFdswUOp6Ru0QmELQNG/8Qbl5ZRqqXGtXJPBhfFok8jJ5owRWg20UmXt732RlTOspi8lhgHO9jMDg==; 5:zJh2PhXb/ZRrVDtjPBxc7fyTlZOP1YPMIeM2T2/PN3sMWMOWczIqVI9/IKgbNSRPpyiPhGiOTTb9iyeoLSif2OI1ijv/n3gvMLm5JnFerOyIQsnTGwBPS9IYSo/tOTVKiQhap/2KlslRH6/4KNqysAeB4L5yf3vkcdc7crjtgR0=; 24:mgkwP4Xn8L4eG+TkCqgCJENSdMzhX6QpQxxJU9Vfrwk8Ji6difBZ+SU/uxorY7OKT+XE/r199tZvcotiwjHJwiXg693OKJySAidjE2Xy6co= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2513; 7:ymfKU4IVPWyolOwfhILQ+/nJyr3dG5hL3ai8JZCSXPcaOjTikUXsP5BgOBoUkqNcpnWcW1TPpv8kwmDSfRzyDLu8T9bS/WsZUsrvFhv5wxwQECu+DhssnmzdpoBgD73aFlBzGu+zRpzCgX4Qu6Wv1mdoaXD05qxV5lixd+2f6Rs+baL6qkP1A7zhi89b+Mh5ZSqitDJpsYlUHinBac+9B4kw4xody+w+r3XYCAzKp203QHwoJlzq3L8gMF7LNm5m X-MS-Office365-Filtering-Correlation-Id: 572d1150-2d25-4a09-b3a3-08d5a6c0bc90 X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2018 13:15:02.6807 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 572d1150-2d25-4a09-b3a3-08d5a6c0bc90 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR07MB2513 Subject: Re: [dpdk-dev] [dpdk-dev, v1, 2/5] eventdev: add crypto adapter implementation 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: Fri, 20 Apr 2018 13:15:08 -0000 -----Original Message----- > Date: Fri, 20 Apr 2018 17:04:36 +0530 > From: Akhil Goyal > To: "Gujjar, Abhinandan S" , > "jerin.jacob@caviumnetworks.com" , > "hemant.agrawal@nxp.com" , "dev@dpdk.org" > > CC: "De Lara Guarch, Pablo" , "Doherty, > Declan" , "Vangati, Narender" > , "Rao, Nikhil" , "Eads, > Gage" > Subject: Re: [dpdk-dev, v1, 2/5] eventdev: add crypto adapter implementation > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 > Thunderbird/45.8.0 > > Hi Abhinandan/ Jerin, > On 4/18/2018 11:51 AM, Gujjar, Abhinandan S wrote: > > Hi Akhil, > > > > Please find the comments inline. > > > > > -----Original Message----- > > > From: Akhil Goyal [mailto:akhil.goyal@nxp.com] > > > Sent: Tuesday, April 17, 2018 7:48 PM > > > To: Gujjar, Abhinandan S ; > > > jerin.jacob@caviumnetworks.com; hemant.agrawal@nxp.com; dev@dpdk.org > > > Cc: De Lara Guarch, Pablo ; Doherty, Declan > > > ; Vangati, Narender > > > ; Rao, Nikhil ; Eads, Gage > > > > > > Subject: Re: [dpdk-dev, v1, 2/5] eventdev: add crypto adapter implementation > > > > > > Hi Abhinandan, > > > > > > I have not reviewed the patch completely. But I have below query for further > > > review. > > > On 4/4/2018 12:26 PM, Abhinandan Gujjar wrote: > > > > Signed-off-by: Abhinandan Gujjar > > > > Signed-off-by: Nikhil Rao > > > > Signed-off-by: Gage Eads > > > > --- > > > > > > [..snip..] > > > > + > > > > +int __rte_experimental > > > > +rte_event_crypto_adapter_queue_pair_add(uint8_t id, > > > > + uint8_t cdev_id, > > > > + int32_t queue_pair_id) > > > > +{ > > > > + struct rte_event_crypto_adapter *adapter; > > > > + struct rte_eventdev *dev; > > > > + struct crypto_device_info *dev_info; > > > > + uint32_t cap; > > > > + int ret; > > > > + > > > > + RTE_EVENT_CRYPTO_ADAPTER_ID_VALID_OR_ERR_RET(id, -EINVAL); > > > > + > > > > + if (!rte_cryptodev_pmd_is_valid_dev(cdev_id)) { > > > > + RTE_EDEV_LOG_ERR("Invalid dev_id=%" PRIu8, cdev_id); > > > > + return -EINVAL; > > > > + } > > > > + > > > > + adapter = eca_id_to_adapter(id); > > > > + if (adapter == NULL) > > > > + return -EINVAL; > > > > + > > > > + dev = &rte_eventdevs[adapter->eventdev_id]; > > > > + ret = rte_event_crypto_adapter_caps_get(adapter->eventdev_id, > > > > + cdev_id, > > > > + &cap); > > > > + if (ret) { > > > > + RTE_EDEV_LOG_ERR("Failed to get adapter caps dev %" PRIu8 > > > > + "cdev %" PRIu8, id, cdev_id); > > > > + return ret; > > > > + } > > > > + > > > > + dev_info = &adapter->cdevs[cdev_id]; > > > > + > > > > + if (queue_pair_id != -1 && > > > > + (uint16_t)queue_pair_id >= dev_info->dev->data->nb_queue_pairs) { > > > > + RTE_EDEV_LOG_ERR("Invalid queue_pair_id %" PRIu16, > > > > + (uint16_t)queue_pair_id); > > > > + return -EINVAL; > > > > + } > > > > + > > > > + if (cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT) { > > > > + RTE_FUNC_PTR_OR_ERR_RET( > > > > + *dev->dev_ops->crypto_adapter_queue_pair_add, > > > > + -ENOTSUP); > > > > + if (dev_info->qpairs == NULL) { > > > > + dev_info->qpairs = > > > > + rte_zmalloc_socket(adapter->mem_name, > > > > + dev_info->dev->data->nb_queue_pairs > > > * > > > > + sizeof(struct crypto_queue_pair_info), > > > > + 0, adapter->socket_id); > > > > + if (dev_info->qpairs == NULL) > > > > + return -ENOMEM; > > > > + } > > > > + > > > > + ret = (*dev->dev_ops->crypto_adapter_queue_pair_add)(dev, > > > > + dev_info->dev, > > > > + queue_pair_id); > > > > > > crypto_adapter_queue_pair_add is supposed to attach a queue > > > (queue_pair_id) of cryptodev(dev_info->dev) to event device (dev). > > > But how will the underlying implementation attach it to event device without > > > knowing the eventdev queue_id. This information was coming in the RFC > > > patches with the parameter (rte_event_crypto_queue_pair_conf). > > > Why is this removed and if removed how will the driver attach the queue. > > > I can see that rte_event is passed in the session private data but how can we > > > attach the crypto queue with event dev queue? > > > > Yes, this was present in the first version of the RFC which is similar to eth rx adapter. > > After couple of discussions, thread http://dpdk.org/dev/patchwork/patch/31752/), > > it was changed. In eth rx adapter, eth queues are mapped to eventdev, whereas in crypto > > adapter the sessions are mapped to eventdev. Since event info is present along with the > > session, the get API has to be called in respective API to get the event information and > > then map to eventdev. > > > > I think the intent of that discussion was misunderstood from our end. > But this is not going to work for hardware devices. > > Because in case of hardware implementation, the scheduling is done in > hardware and hardware cannot call the get API to get the event information > then map to event device. Actually the scheduling has happened before the > crypto_op is dequeued from the event port. So there is no point of set/get > private data in our case. > > We need to map the crypto queues to the event queue_ids at the time of > queue_pair add API. In hardware scheduler, we map n(may be 1-8) crypto > queues to m event queues(<= n). We can assign multiple sessions to any > crypto queue pair, and after the crypto op is received by event queue, they > are appropriately scheduled by hardware to event ports. > > Session based mapping to event queue cannot be supported. Our design is same > as that of eth rx adapter. Crypto queue pair to eventdev queue mapping should be supported. But That's a limited set. meaning if an application needs millions of IPSec SA sessions then we can not map it. So, IMO, If an HW/SW can not support session based mapping then it needs to be exposed/abstracted through capabilities. crypto qp to event queue mapping will be supported in all adapter implementation. Does that sounds OK? > > Akhil >