Message ID | 20170323080648.7149-2-akhil.goyal@nxp.com (mailing list archive) |
---|---|
State | Superseded, archived |
Delegated to: | Pablo de Lara Guarch |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id D10075599; Thu, 23 Mar 2017 09:07:55 +0100 (CET) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0086.outbound.protection.outlook.com [104.47.41.86]) by dpdk.org (Postfix) with ESMTP id A9F0A1396 for <dev@dpdk.org>; Thu, 23 Mar 2017 09:07:36 +0100 (CET) Received: from BN6PR03CA0085.namprd03.prod.outlook.com (10.164.122.151) by DM5PR03MB2793.namprd03.prod.outlook.com (10.168.198.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 23 Mar 2017 08:07:35 +0000 Received: from BL2FFO11FD050.protection.gbl (2a01:111:f400:7c09::174) by BN6PR03CA0085.outlook.office365.com (2603:10b6:405:6f::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.961.14 via Frontend Transport; Thu, 23 Mar 2017 08:07:35 +0000 Authentication-Results: spf=fail (sender IP is 192.88.168.50) smtp.mailfrom=nxp.com; nxp.com; dkim=none (message not signed) header.d=none;nxp.com; dmarc=fail action=none header.from=nxp.com; Received-SPF: Fail (protection.outlook.com: domain of nxp.com does not designate 192.88.168.50 as permitted sender) receiver=protection.outlook.com; client-ip=192.88.168.50; helo=tx30smr01.am.freescale.net; Received: from tx30smr01.am.freescale.net (192.88.168.50) by BL2FFO11FD050.mail.protection.outlook.com (10.173.161.212) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.977.7 via Frontend Transport; Thu, 23 Mar 2017 08:07:35 +0000 Received: from netperf2.ap.freescale.net ([10.232.133.164]) by tx30smr01.am.freescale.net (8.14.3/8.14.0) with ESMTP id v2N87JhI011770; Thu, 23 Mar 2017 01:07:32 -0700 From: <akhil.goyal@nxp.com> To: <dev@dpdk.org> CC: <sergio.gonzalez.monroy@intel.com>, <declan.doherty@intel.com>, <pablo.de.lara.guarch@intel.com>, <fiona.trahe@intel.com>, <hemant.agrawal@nxp.com>, Akhil Goyal <akhil.goyal@nxp.com> Date: Thu, 23 Mar 2017 13:36:48 +0530 Message-ID: <20170323080648.7149-2-akhil.goyal@nxp.com> X-Mailer: git-send-email 2.9.3 In-Reply-To: <20170323080648.7149-1-akhil.goyal@nxp.com> References: <20170317084510.2120-1-akhil.goyal@nxp.com> <20170323080648.7149-1-akhil.goyal@nxp.com> X-EOPAttributedMessage: 0 X-Matching-Connectors: 131347300555752825; (91ab9b29-cfa4-454e-5278-08d120cd25b8); () X-Forefront-Antispam-Report: CIP:192.88.168.50; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(336005)(39850400002)(39840400002)(39400400002)(39380400002)(39860400002)(39410400002)(39450400003)(2980300002)(1110001)(1109001)(339900001)(199003)(189002)(9170700003)(50226002)(5003940100001)(2906002)(575784001)(356003)(8676002)(305945005)(86362001)(106466001)(189998001)(50466002)(8656002)(33646002)(38730400002)(86152003)(48376002)(77096006)(110136004)(54906002)(2351001)(105606002)(4326008)(8936002)(81166006)(53936002)(47776003)(85426001)(1076002)(2876002)(36756003)(104016004)(50986999)(2950100002)(6666003)(6916009)(5890100001)(76176999)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR03MB2793; H:tx30smr01.am.freescale.net; FPR:; SPF:Fail; MLV:ovrnspm; A:1; MX:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD050; 1:qmEmIOk01sZdtbRrVLc4165IOHqn3TYLjNLkbaaR3FKuuI0V3eEc6Yoi84mYO55gWOS4quFjcmKQPlFO7g0KM47+kX2OoYB1QK+V2hI7bMGLS8hQPX6jpnrn26wEAfnCVLxFyZ/Iq7RuE7V1mOGEsxKJiN0ibupd3YUIvbKIRX0Sw/4UQM6C/nPmjEinDyfyxMz2UbixMJbFcYHvxyXToaN+75wVlLSo/Kac+0rW5IGYaBqdNXEc+TLMdoNUIhW5T9SXLdjbUuB3lxSp0l6vEfduVvE/gNgCFEmWWTRqqF23NztNRrhinzPYRKEwoAc8+rv+xqdWLMDdqORVsI2ZnsdHyitRw6SmLdmPKibwoZhrj8h2FnJFYpBqnYcDe7zQFTNELEq5djs0brTcUM527sxqXEfFk7P90+HHa6a1PElN/EljkP72EU+HjzG9bSzlXmJ0WCkYKB8RapdTlJIJDRmGqpNhkqkgEhHcxe44dfiE//AWBxRXom9Gr6nVPmMeaqowujoxA2oKqpKv6Ssf/owbRGmSrkVCMg7wg5tvU5hVEJieGkvoquhVwZwDRiZabzFfBIUpv9dtBxoMgOgeUMg6CAHhu87bFPkWbUuayaXbB4WW5juZ0flYFqu1u3fSSjiptKW3EatT1DR1Da2hS0eW983RYLwEakFd/yGvg8cE1RTZRLyUAGHDReemRIyepuo0gjd87UwZ8Txg+KGdyPnNYlKl5v0pigB2Q38OK+hpUROVUiXboQvRwfTrV2yB MIME-Version: 1.0 Content-Type: text/plain X-MS-Office365-Filtering-Correlation-Id: ce3a3531-ad9c-4818-9922-08d471c3aa36 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:DM5PR03MB2793; X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2793; 3:PD+o5hjJkEBHc3a+Oa1+Xh42w5x0cywu/pnBvHts1Kf1Sz2BEz0vHdAnNNRaOp48MxXNBml2viAaCzqIy4r1ovHhM+QnodQAcucNYNv0tq9cJsXRWet+TtKwVRd4ybE8zY3p6oWLyWVvdGkowV5ipJUSzohJvECq44x5Cwkszu5GJjRvo/cndlUeunxXp9ufQIGAQlZiILaZRC8I/izTDi4iikdR31qJPf1JcGeqTn1Ft6gG/6tyTAVsdeU4rfv9twF8d9PXSd8nxdA1l3QZIAgix4G3igglxC3G2u9yO3YgVzZSADetfXK3awATjr59HL5gtkiP6g+pbjh/C+qly0KNlrSso0Ug56SmafIS2imij/aU+0gMzVc9UAltfTbK; 25:IRDsFGfl9A1tBjgVShvuGDtpnUVw8onZU/eWXk4UOloCivE+TbSQMarhCw+3/V6X+hykToiPyxqYZCoIA8MBnlKS/AbDXFHDHcJrltheQcv+yzSDWFtxHHvrAdBHGmyOjK0beIUZpwlpYpHL/Jcnu9naxxmZEAS4bQG0uEuHHdvh3G/FSngDFlfI3zN65Kh9PlfbwibX8LVnfSqhBk2D30/Jf81lHhELSMF3T2/2nZdqcdA/SsrsaK7Jj5tg2XycX0JDkWAL26BUoPwhKJs/CGa8f94yKkNQsGLM+WmrBo3/W0ECb/WGAf31F4MaBQ/sy6I+r5FHlgInVgR6HYjU1gcJk7liNtSMGoCjjP4/KKplymLlkNzjN3cWEV25goEoN0J0G+d2sJb1gzimSp0i6D6is9mjoHOmkJ2dFDYl/+n205OsGsHBJBA7pYPalaHURwcfVXfOwHgIcrzI5S6elQ== X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2793; 31:5QdmuofbfFC4NI6RZ5aL72OdsrVZ8EpeebUc55sSR+M98QQ2mVkj0hrkYdtDUtycoCIh+YuIa54F+C6PthokQSADCAp2NRYLHuGO21+NjYE358e98zPx2mAZEgmH2nfp8Fozx4ySQoWkubKQMPPu/o5PsLmILjcZ5ZQ9ffl3HtKdxVHAL4xMjhrQJ9vKu1jyOAnu/CmzBZztSyCCLuTjw/DYPoyyO1oBV989FDulg2f9R6XthrcGB3LYoAPrEEOvHw002hCboW7TlXGGES/vUVK7JLSk1t2+axsFyH935hY= X-Microsoft-Antispam-PRVS: <DM5PR03MB2793DC894CF6A0FA754F4784E63F0@DM5PR03MB2793.namprd03.prod.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:(185117386973197); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6095060)(601004)(2401047)(13023025)(5005006)(13024025)(8121501046)(13015025)(13017025)(13018025)(3002001)(10201501046)(6055026)(6096035)(20161123565025)(20161123563025)(20161123556025)(20161123559025)(20161123561025); SRVR:DM5PR03MB2793; BCL:0; PCL:0; RULEID:(400006); SRVR:DM5PR03MB2793; X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2793; 4:ksBM6X1ku5AEbLJYP06n8sgIGdFHNFcYrBSl5K2GfygA5V3YUdusVeFgMZoK3R7dBi/2nPON046xkbv1vVSnucbJnx8T9x4Sfn0A7uTSw6Den7H9Em/36UFXcKAhC4A5J//qNvrMl9VKLMyo97GB0Ih/nz8QfmY0rhIl15V1prpBmd8HhPZisBnhU4m0zEMjIxEfQ2/PEJEZr6bXIyMFfHeRHBLrh+ZgMFTXwDGIYLgizz49DTcexIA23Rg3znW24TqTs74Cfx66FwbLP05hI9chWZH08+1jkJniwMqdUdCKyjjYxOBp4siQtnXb6caFgy69je+kpc/ilhq+nlRId0u1WKsoUIrP5jT7dUqZ0JfFh7QvmEQx4fj+mW5ES6YFcXJ2/ITEuTiSWnvB7yVyarshNK5ExQadlN0HWyY3lGZw4P+wYvPdoiVbKfq3Bl3gmSF8amJvd8BcT+YoidYR7uRBCb1/nq6LK1j9de4JaWsCR0Z79NrVxmdaH4YszDe9AqBV5wbiSDD9ZKhRoXY29uekrLiYfTl1B+M4CJBhp3KZEnRYKbBIoUXRPEdLlVrI6se51ajgQN33EbDRip1uMw+NgFmrHrD8RWpOnEO0cJmkK/ulKqpj6ISysjOVMTbXrGgKxvnvNFGaMFgAaQNQ8Eo8CY8gP9KzeTdbxUz9IN8T5YM+fbhL3hHdHyBG37q0KRpZQynnzXxF8UbPpOROLlp7vXdJkhfEaAkb8p0G8egnyofavqYTQ3FqeprEnGBX X-Forefront-PRVS: 0255DF69B9 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR03MB2793; 23:WszHTMFBa5RkC6DOyTwq9YPIcuibtBuX6R/xgx2MG?= qbrdn8QaqV9FOnootLzdE9sQqfIkNwRbOhYPOkBWi2Ek6XPrgPhSWPbFYCf7cdHIUlbZDDdZFkueyELopwUoDSHvEmnZDWgDMp7/eOM5TA9uoc/DBu+QWSl/mV+C3nUDioUtDuiQmozw0iElJO0oS01x7hz3gQokAHXhegXVLGDpRjZFc5pJq2+40WVZ4A0Vki8PSijkq5/mEp3Ia6hirpNQgGqMo9EdIrUjaAIRVhrQuppz6IXV6tI43LBB1X+6WkQzmIrDxEYoXKlgEHsRhaWbExFYSY4Vdk10qIYZIaJ4S8p6OEnTLLAFGlZvMPhJspw8C2SvPgjIj7cW8F4b9OsKbKN+GE3oCgX5fFYEKu7fRItM+frrkb7aHvzO50TUA9fz6iHLrt82sF8uufY5p3IT7QEIwQ3OFGtfaJADWG2WadZ36x4zIIpkCSbrKUbAHd+5edbRKka4CJ2fGLTYvk+nTobKi6xKBs9+F+uHhqxsc0lOTo5Xywvf++kEx1eP0odAazF97zXHijSpHNarvPYzZny/8/e670+TLGjjJIzczV454fdxAEu/TNFh9WZkOcWbC5NTXNGU3XH4YozmTJ25nvbTM0oCm4h8Ydh5/NCpg8Z21Z6UGnPu/pOkkG/HcLGGUX2XBa90KcwD88PRLU2naZdI4ZyGKgEF+xPPejanAwuqglwSDBhHwcJq2cwf9Ab8QyMckEtPwO1hkFk0cCYJOPlU8lBoyL+a8068RwcdmYIRYjj3kTk21fnNhVOl8GpoV9/2DbJMteK6bMu/rGmPG7NXjRnOQ0gdihnbNbfpAppWIoxuX29jaNY/bDSJzpXKg4ZTjGdkZ3u4tqvTa7Eb0BlNz4ss2NfJvY+igGJJGhfj+vcXNcNCXEzS/oaxN5i4f1HIvq+JL2/oRbeWWEV6aLIov7+ek7Qb3hA94zNzUVITSiMYdBf05v9kZmG+W7yyTrJrqTayiQwtmZ7WZA1txK1+mbTtVEZ0YotFTfk0Pt+KifqmTikgtEfNyOaLhGyEehRr5g1ibbfXlB2hyxOvR8VISAnsD7mldfmIIssnpJ/lZk4YXlUjjtSdTDtReQhx0KDjudDMD5dIgk2mmLvlfrJvp3EbqQZ5n8yRla0eJpTlGloXWG/sS8ZxBotfmST0GJW5PmGWL3Bz6gfCJDt9wnUzIaog1UIMeIZXlfzXXTSmlxHklv/QvvxSsV7/5Ba+0RKOQr/SFdao6X8e7SkTH960Cuw1ulLLI4ap3DsWXHLpScER1g1pAVJ5V8El8AyCLNbfWH2uCQD77HSLaxz X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2793; 6:894As4pwYlECSdq+JQfXSYErsQuoSnW/wiDF58xdc9PCTlZXrBhAw0zTr85B0jndgOTSxSBLBnvse3UbiqSmyxpXgt08JrUd0JVSP5iS9YqnWixdIf1B6GdBxh4J2aJl8wsgmNE5sBTQP9nXkG1Y10JdCBQaLbGxTHyPOkruI3p66yTSOJROINTzkGpEGPbF8Q+bykBqFixDKZ8lBttplmYBqFjeFas7dKtyAXP9XbpA5DtnrMcF3GaOg7HsHrxHZL21Im6h3Q3AjMR+ngilG9q2JNF/g4287ksRxpiX5Wlonz7Yn+W0vxq8RjopWZejccradZJl//FMvY4P2Wa/Ikla5GV0NDP9mtsCLF1O1iI1quAXsJOjYfdAuQaxIWuJP/+663JAVKvpf1eK8QHVuNIpJV4xtxZtmsMnn6vAqgo=; 5:R69cu1vtQ7amrrS1bNTOx7bSINPc21wRdYxfe5ZLBaeBIQ2S0zebK9FwuwBTYQoc9VG7bZwa6hGOED/SvZUKnu9BQYzgyBrXcOfMtlcsaYKthaqG2h6nwwp6iS+TNosPBZ137cKD9X45/k1D7QkOwprQNcrzE3LRBr9M4zEGMgGJRuDuCwiFWpwX/NzJP3sH; 24:wO+ziLvAab+cVnvUnPwyQF1WXMos00uRTnUuT/0t8sjSslaSZQAMqOzoSSZTU0Ihe1OO/pEE6EVahWIqa2BI5NFeruLjlEq7yxjhg+JWiI0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2793; 7:Fszc2MDFe9irV2eEBxcQ9XXfd6CFsHT4jmDCJVcvlNRef93xxTfJq7srgsCu7uITum4nEKiL1qlRaVlQDzFQ/Ps7vIzTf4FrjhXqIok4LKQ/h8kp0JMeuCDQ3Zw8uDyFAEEm3C4XU/IFIYoep/yCSZIpKqvqimKH7NmPUxSqaqY/Gp5Cx6FQ5HD+wkKabtOlSi9DdcFzovur0bwuNUZ/nxeHQiiXUkHEmdZKwnnd12escqgUP1VzVzzACYnXGPkz7sXuRP7XUgbX+lwdVZSclWsdfyObwlZ9g34lNM5rJ+Ffaz53cSMoqAM6qzO6KUodnShJ2UxS09sRfW2Qm4JNmQ== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Mar 2017 08:07:35.2632 (UTC) X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[192.88.168.50]; Helo=[tx30smr01.am.freescale.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR03MB2793 Subject: [dpdk-dev] [PATCH v2 2/2] examples/ipsec-secgw: attach session-qp X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Checks
Context | Check | Description |
---|---|---|
ci/checkpatch | success | coding style OK |
ci/Intel-compilation | success | Compilation OK |
Commit Message
Akhil Goyal
March 23, 2017, 8:06 a.m. UTC
From: Akhil Goyal <akhil.goyal@nxp.com> adding support for attaching session to queue pairs. This is required as underlying crypto driver may only support limited number of sessions per queue pair if max_nb_sessions_per_qp > 0, session should be attached to a particular qp. Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com> --- examples/ipsec-secgw/ipsec.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
Comments
That was simpler than I thought. For some reason I understood that the device will support thousands of queues and single session per queue which would have needed more app changes. On 23/03/2017 08:06, akhil.goyal@nxp.com wrote: > From: Akhil Goyal <akhil.goyal@nxp.com> > > adding support for attaching session to queue pairs. > This is required as underlying crypto driver may only > support limited number of sessions per queue pair > if max_nb_sessions_per_qp > 0, session should be > attached to a particular qp. > > Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com> > --- > examples/ipsec-secgw/ipsec.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c > index 144f0aa..b35b30f 100644 > --- a/examples/ipsec-secgw/ipsec.c > +++ b/examples/ipsec-secgw/ipsec.c > @@ -47,6 +47,7 @@ > static inline int > create_session(struct ipsec_ctx *ipsec_ctx __rte_unused, struct ipsec_sa *sa) > { > + struct rte_cryptodev_info cdev_info; > unsigned long cdev_id_qp = 0; > int32_t ret; > struct cdev_key key = { 0 }; > @@ -73,6 +74,17 @@ create_session(struct ipsec_ctx *ipsec_ctx __rte_unused, struct ipsec_sa *sa) > sa->crypto_session = rte_cryptodev_sym_session_create( > ipsec_ctx->tbl[cdev_id_qp].id, sa->xforms); > > + rte_cryptodev_info_get(ipsec_ctx->tbl[cdev_id_qp].id, &cdev_info); > + if (cdev_info.sym.max_nb_sessions_per_qp > 0) { > + ret = rte_cryptodev_queue_pair_attach_sym_session( > + ipsec_ctx->tbl[cdev_id_qp].qp, > + sa->crypto_session); > + if (ret < 0) { > + RTE_LOG(ERR, IPSEC, "Session cannot be attached" > + " to qp %u ", ipsec_ctx->tbl[cdev_id_qp].qp); Guideline is to keep error strings in single line to facilitate grep. Other than that: Acked-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> > + return -1; > + } > + } > sa->cdev_id_qp = cdev_id_qp; > > return 0;
On 3/23/2017 4:00 PM, Sergio Gonzalez Monroy wrote: > That was simpler than I thought. > > For some reason I understood that the device will support thousands of > queues and single session per queue which would have needed more app > changes. > > On 23/03/2017 08:06, akhil.goyal@nxp.com wrote: >> From: Akhil Goyal <akhil.goyal@nxp.com> >> >> adding support for attaching session to queue pairs. >> This is required as underlying crypto driver may only >> support limited number of sessions per queue pair >> if max_nb_sessions_per_qp > 0, session should be >> attached to a particular qp. >> >> Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com> >> --- >> examples/ipsec-secgw/ipsec.c | 12 ++++++++++++ >> 1 file changed, 12 insertions(+) >> >> diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c >> index 144f0aa..b35b30f 100644 >> --- a/examples/ipsec-secgw/ipsec.c >> +++ b/examples/ipsec-secgw/ipsec.c >> @@ -47,6 +47,7 @@ >> static inline int >> create_session(struct ipsec_ctx *ipsec_ctx __rte_unused, struct >> ipsec_sa *sa) >> { >> + struct rte_cryptodev_info cdev_info; >> unsigned long cdev_id_qp = 0; >> int32_t ret; >> struct cdev_key key = { 0 }; >> @@ -73,6 +74,17 @@ create_session(struct ipsec_ctx *ipsec_ctx >> __rte_unused, struct ipsec_sa *sa) >> sa->crypto_session = rte_cryptodev_sym_session_create( >> ipsec_ctx->tbl[cdev_id_qp].id, sa->xforms); >> + rte_cryptodev_info_get(ipsec_ctx->tbl[cdev_id_qp].id, &cdev_info); >> + if (cdev_info.sym.max_nb_sessions_per_qp > 0) { >> + ret = rte_cryptodev_queue_pair_attach_sym_session( >> + ipsec_ctx->tbl[cdev_id_qp].qp, >> + sa->crypto_session); >> + if (ret < 0) { >> + RTE_LOG(ERR, IPSEC, "Session cannot be attached" >> + " to qp %u ", ipsec_ctx->tbl[cdev_id_qp].qp); > > Guideline is to keep error strings in single line to facilitate grep. > Other than that: > > Acked-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> > >> + return -1; >> + } >> + } >> sa->cdev_id_qp = cdev_id_qp; >> return 0; > > > Hi Sergio, Similar error string is mentioned above my change also in the same function. I deliberately did that as per the error strings in the file. Thanks, Akhil
On 23/03/2017 10:38, Akhil Goyal wrote: > On 3/23/2017 4:00 PM, Sergio Gonzalez Monroy wrote: >> That was simpler than I thought. >> >> For some reason I understood that the device will support thousands of >> queues and single session per queue which would have needed more app >> changes. >> >> On 23/03/2017 08:06, akhil.goyal@nxp.com wrote: >>> From: Akhil Goyal <akhil.goyal@nxp.com> >>> >>> adding support for attaching session to queue pairs. >>> This is required as underlying crypto driver may only >>> support limited number of sessions per queue pair >>> if max_nb_sessions_per_qp > 0, session should be >>> attached to a particular qp. >>> >>> Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com> >>> --- >>> examples/ipsec-secgw/ipsec.c | 12 ++++++++++++ >>> 1 file changed, 12 insertions(+) >>> >>> diff --git a/examples/ipsec-secgw/ipsec.c >>> b/examples/ipsec-secgw/ipsec.c >>> index 144f0aa..b35b30f 100644 >>> --- a/examples/ipsec-secgw/ipsec.c >>> +++ b/examples/ipsec-secgw/ipsec.c >>> @@ -47,6 +47,7 @@ >>> static inline int >>> create_session(struct ipsec_ctx *ipsec_ctx __rte_unused, struct >>> ipsec_sa *sa) >>> { >>> + struct rte_cryptodev_info cdev_info; >>> unsigned long cdev_id_qp = 0; >>> int32_t ret; >>> struct cdev_key key = { 0 }; >>> @@ -73,6 +74,17 @@ create_session(struct ipsec_ctx *ipsec_ctx >>> __rte_unused, struct ipsec_sa *sa) >>> sa->crypto_session = rte_cryptodev_sym_session_create( >>> ipsec_ctx->tbl[cdev_id_qp].id, sa->xforms); >>> + rte_cryptodev_info_get(ipsec_ctx->tbl[cdev_id_qp].id, &cdev_info); >>> + if (cdev_info.sym.max_nb_sessions_per_qp > 0) { >>> + ret = rte_cryptodev_queue_pair_attach_sym_session( >>> + ipsec_ctx->tbl[cdev_id_qp].qp, >>> + sa->crypto_session); >>> + if (ret < 0) { >>> + RTE_LOG(ERR, IPSEC, "Session cannot be attached" >>> + " to qp %u ", ipsec_ctx->tbl[cdev_id_qp].qp); >> >> Guideline is to keep error strings in single line to facilitate grep. >> Other than that: >> >> Acked-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> >> >>> + return -1; >>> + } >>> + } >>> sa->cdev_id_qp = cdev_id_qp; >>> return 0; >> >> >> > Hi Sergio, > > Similar error string is mentioned above my change also in the same > function. I deliberately did that as per the error strings in the file. > > Thanks, > Akhil > That means that we need to update those strings too, but new code should try to keep error string in single line. Thanks, Sergio
On 3/23/2017 4:13 PM, Sergio Gonzalez Monroy wrote: > On 23/03/2017 10:38, Akhil Goyal wrote: >> On 3/23/2017 4:00 PM, Sergio Gonzalez Monroy wrote: >>> That was simpler than I thought. >>> >>> For some reason I understood that the device will support thousands of >>> queues and single session per queue which would have needed more app >>> changes. >>> >>> On 23/03/2017 08:06, akhil.goyal@nxp.com wrote: >>>> From: Akhil Goyal <akhil.goyal@nxp.com> >>>> >>>> adding support for attaching session to queue pairs. >>>> This is required as underlying crypto driver may only >>>> support limited number of sessions per queue pair >>>> if max_nb_sessions_per_qp > 0, session should be >>>> attached to a particular qp. >>>> >>>> Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com> >>>> --- >>>> examples/ipsec-secgw/ipsec.c | 12 ++++++++++++ >>>> 1 file changed, 12 insertions(+) >>>> >>>> diff --git a/examples/ipsec-secgw/ipsec.c >>>> b/examples/ipsec-secgw/ipsec.c >>>> index 144f0aa..b35b30f 100644 >>>> --- a/examples/ipsec-secgw/ipsec.c >>>> +++ b/examples/ipsec-secgw/ipsec.c >>>> @@ -47,6 +47,7 @@ >>>> static inline int >>>> create_session(struct ipsec_ctx *ipsec_ctx __rte_unused, struct >>>> ipsec_sa *sa) >>>> { >>>> + struct rte_cryptodev_info cdev_info; >>>> unsigned long cdev_id_qp = 0; >>>> int32_t ret; >>>> struct cdev_key key = { 0 }; >>>> @@ -73,6 +74,17 @@ create_session(struct ipsec_ctx *ipsec_ctx >>>> __rte_unused, struct ipsec_sa *sa) >>>> sa->crypto_session = rte_cryptodev_sym_session_create( >>>> ipsec_ctx->tbl[cdev_id_qp].id, sa->xforms); >>>> + rte_cryptodev_info_get(ipsec_ctx->tbl[cdev_id_qp].id, &cdev_info); >>>> + if (cdev_info.sym.max_nb_sessions_per_qp > 0) { >>>> + ret = rte_cryptodev_queue_pair_attach_sym_session( >>>> + ipsec_ctx->tbl[cdev_id_qp].qp, >>>> + sa->crypto_session); >>>> + if (ret < 0) { >>>> + RTE_LOG(ERR, IPSEC, "Session cannot be attached" >>>> + " to qp %u ", ipsec_ctx->tbl[cdev_id_qp].qp); >>> >>> Guideline is to keep error strings in single line to facilitate grep. >>> Other than that: >>> >>> Acked-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> >>> >>>> + return -1; >>>> + } >>>> + } >>>> sa->cdev_id_qp = cdev_id_qp; >>>> return 0; >>> >>> >>> >> Hi Sergio, >> >> Similar error string is mentioned above my change also in the same >> function. I deliberately did that as per the error strings in the file. >> >> Thanks, >> Akhil >> > > That means that we need to update those strings too, but new code should > try to keep error string in single line. > > Thanks, > Sergio > Ok I would correct the string. Will send the v3 with this change only if there is no more comments from Fiona. Thanks, Akhil
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c index 144f0aa..b35b30f 100644 --- a/examples/ipsec-secgw/ipsec.c +++ b/examples/ipsec-secgw/ipsec.c @@ -47,6 +47,7 @@ static inline int create_session(struct ipsec_ctx *ipsec_ctx __rte_unused, struct ipsec_sa *sa) { + struct rte_cryptodev_info cdev_info; unsigned long cdev_id_qp = 0; int32_t ret; struct cdev_key key = { 0 }; @@ -73,6 +74,17 @@ create_session(struct ipsec_ctx *ipsec_ctx __rte_unused, struct ipsec_sa *sa) sa->crypto_session = rte_cryptodev_sym_session_create( ipsec_ctx->tbl[cdev_id_qp].id, sa->xforms); + rte_cryptodev_info_get(ipsec_ctx->tbl[cdev_id_qp].id, &cdev_info); + if (cdev_info.sym.max_nb_sessions_per_qp > 0) { + ret = rte_cryptodev_queue_pair_attach_sym_session( + ipsec_ctx->tbl[cdev_id_qp].qp, + sa->crypto_session); + if (ret < 0) { + RTE_LOG(ERR, IPSEC, "Session cannot be attached" + " to qp %u ", ipsec_ctx->tbl[cdev_id_qp].qp); + return -1; + } + } sa->cdev_id_qp = cdev_id_qp; return 0;