| Message ID | 20211011124309.4066491-1-gakhil@marvell.com (mailing list archive) |
|---|---|
| Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 56285A034F; Mon, 11 Oct 2021 14:43:31 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E152140E0F; Mon, 11 Oct 2021 14:43:30 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by mails.dpdk.org (Postfix) with ESMTP id E293E40E01 for <dev@dpdk.org>; Mon, 11 Oct 2021 14:43:28 +0200 (CEST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19BCYKZN002406; Mon, 11 Oct 2021 05:43:22 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type; s=pfpt0220; bh=1gxc1Rf+1UkwmoZqhBl4FjCmZvrjmnPueUwpSAxcVWE=; b=T0LxFk4tPU2/sLmhQrXfBrPOh59vo2t5MwFn92mQtLI0+ZZegUd8s5kh6MAqMmc1LELZ sOs4WCuzjk7Vrm2fKd/9mgV+uXhSsgWzH7xaefcqk6ovP4rK9+uXST9yUZ55mdCuVl9g sgnmaeGXPHWABONGXdq/fqZK6O2ZrDEVD6Unqr5lnUSswuJuFfvO5QcvJC4xRR5cdB6m nr65pjW+WPsQ7cMxg4M715E+hbVojpTDT2rMA3o2/eMmm9H/Jgcgq03U6dLaLcPrCMFD AYr4zwO97sWHYCRqzCTa9WcbuzWSSwYWyDQTs3cJHFEiZWB5C8TxIAxPu9Ux/7q8Wwl2 vA== Received: from dc5-exch02.marvell.com ([199.233.59.182]) by mx0a-0016f401.pphosted.com with ESMTP id 3bmaa5tayd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 11 Oct 2021 05:43:22 -0700 Received: from DC5-EXCH01.marvell.com (10.69.176.38) by DC5-EXCH02.marvell.com (10.69.176.39) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 11 Oct 2021 05:43:21 -0700 Received: from maili.marvell.com (10.69.176.80) by DC5-EXCH01.marvell.com (10.69.176.38) with Microsoft SMTP Server id 15.0.1497.18 via Frontend Transport; Mon, 11 Oct 2021 05:43:20 -0700 Received: from localhost.localdomain (unknown [10.28.36.185]) by maili.marvell.com (Postfix) with ESMTP id B08CA3F707B; Mon, 11 Oct 2021 05:43:15 -0700 (PDT) From: Akhil Goyal <gakhil@marvell.com> To: <dev@dpdk.org> CC: <thomas@monjalon.net>, <david.marchand@redhat.com>, <hemant.agrawal@nxp.com>, <anoobj@marvell.com>, <pablo.de.lara.guarch@intel.com>, <fiona.trahe@intel.com>, <declan.doherty@intel.com>, <matan@nvidia.com>, <g.singh@nxp.com>, <roy.fan.zhang@intel.com>, <jianjay.zhou@huawei.com>, <asomalap@amd.com>, <ruifeng.wang@arm.com>, <konstantin.ananyev@intel.com>, <radu.nicolau@intel.com>, <ajit.khaparde@broadcom.com>, <rnagadheeraj@marvell.com>, <adwivedi@marvell.com>, <ciara.power@intel.com>, Akhil Goyal <gakhil@marvell.com> Date: Mon, 11 Oct 2021 18:13:04 +0530 Message-ID: <20211011124309.4066491-1-gakhil@marvell.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210829125139.2173235-1-gakhil@marvell.com> References: <20210829125139.2173235-1-gakhil@marvell.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Proofpoint-GUID: 0wNWDW2r5NymSGRjwMzr-7FGaoYYj1FN X-Proofpoint-ORIG-GUID: 0wNWDW2r5NymSGRjwMzr-7FGaoYYj1FN X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-11_04,2021-10-07_02,2020-04-07_01 Subject: [dpdk-dev] [PATCH v2 0/5] cryptodev: hide internal structures X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
| Series |
cryptodev: hide internal structures
|
|
Message
Akhil Goyal
Oct. 11, 2021, 12:43 p.m. UTC
Structures rte_cryptodev and rte_cryptodev_data are not supposed to be directly used by the application. These are made public as they are used by inline datapath public APIs. This patchset, creates a new rte_cryptodev_core.h file which helps in defining a data structure to hold datapath APIs in a flat array based on the device identifier which is filled by the PMD. Similar series for ethdev and eventdev are also floated on ML. https://patchwork.dpdk.org/project/dpdk/list/?series=19428 https://patchwork.dpdk.org/project/dpdk/list/?series=19405 changes in v2: align with the latest versions of above series. Akhil Goyal (5): cryptodev: separate out internal structures cryptodev: allocate max space for internal qp array cryptodev: move inline APIs into separate structure cryptodev: update fast path APIs to use new flat array cryptodev: move device specific structures drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 1 - drivers/crypto/ccp/ccp_dev.h | 2 +- drivers/crypto/cnxk/cn10k_ipsec.c | 2 +- drivers/crypto/cnxk/cn9k_ipsec.c | 2 +- .../crypto/cnxk/cnxk_cryptodev_capabilities.c | 2 +- drivers/crypto/cnxk/cnxk_cryptodev_sec.c | 2 +- drivers/crypto/nitrox/nitrox_sym_reqmgr.c | 2 +- drivers/crypto/octeontx/otx_cryptodev.c | 1 - .../crypto/octeontx/otx_cryptodev_hw_access.c | 2 +- .../crypto/octeontx/otx_cryptodev_hw_access.h | 2 +- drivers/crypto/octeontx/otx_cryptodev_ops.h | 2 +- .../crypto/octeontx2/otx2_cryptodev_mbox.c | 2 +- drivers/crypto/scheduler/scheduler_failover.c | 2 +- .../crypto/scheduler/scheduler_multicore.c | 2 +- .../scheduler/scheduler_pkt_size_distr.c | 2 +- .../crypto/scheduler/scheduler_roundrobin.c | 2 +- drivers/event/cnxk/cnxk_eventdev.h | 2 +- drivers/event/dpaa/dpaa_eventdev.c | 2 +- drivers/event/dpaa2/dpaa2_eventdev.c | 2 +- drivers/event/octeontx/ssovf_evdev.c | 2 +- .../event/octeontx2/otx2_evdev_crypto_adptr.c | 2 +- lib/cryptodev/cryptodev_pmd.c | 51 +++ lib/cryptodev/cryptodev_pmd.h | 82 +++- lib/cryptodev/meson.build | 4 +- lib/cryptodev/rte_cryptodev.c | 50 ++- lib/cryptodev/rte_cryptodev.h | 367 +++++++----------- lib/cryptodev/rte_cryptodev_core.h | 62 +++ lib/cryptodev/version.map | 7 +- 28 files changed, 398 insertions(+), 265 deletions(-) create mode 100644 lib/cryptodev/rte_cryptodev_core.h
Comments
Hi Akhil, The approach looks great but we may have to check if it works in multi-process environment - since all enqueue/dequeue handlers are set by primary process the secondary process may not recognize the fp_ops data. We will run a quick test to see if it is true. Regards, Fan > -----Original Message----- > From: Akhil Goyal <gakhil@marvell.com> > Sent: Monday, October 11, 2021 1:43 PM > To: dev@dpdk.org > Cc: thomas@monjalon.net; david.marchand@redhat.com; > hemant.agrawal@nxp.com; anoobj@marvell.com; De Lara Guarch, Pablo > <pablo.de.lara.guarch@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>; > Doherty, Declan <declan.doherty@intel.com>; matan@nvidia.com; > g.singh@nxp.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>; > jianjay.zhou@huawei.com; asomalap@amd.com; ruifeng.wang@arm.com; > Ananyev, Konstantin <konstantin.ananyev@intel.com>; Nicolau, Radu > <radu.nicolau@intel.com>; ajit.khaparde@broadcom.com; > rnagadheeraj@marvell.com; adwivedi@marvell.com; Power, Ciara > <ciara.power@intel.com>; Akhil Goyal <gakhil@marvell.com> > Subject: [PATCH v2 0/5] cryptodev: hide internal structures > > Structures rte_cryptodev and rte_cryptodev_data are not > supposed to be directly used by the application. These > are made public as they are used by inline datapath > public APIs. > This patchset, creates a new rte_cryptodev_core.h file > which helps in defining a data structure to hold datapath > APIs in a flat array based on the device identifier which > is filled by the PMD. > > Similar series for ethdev and eventdev are also floated on ML. > https://patchwork.dpdk.org/project/dpdk/list/?series=19428 > https://patchwork.dpdk.org/project/dpdk/list/?series=19405 > > changes in v2: align with the latest versions of above series. > > Akhil Goyal (5): > cryptodev: separate out internal structures > cryptodev: allocate max space for internal qp array > cryptodev: move inline APIs into separate structure > cryptodev: update fast path APIs to use new flat array > cryptodev: move device specific structures > > drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 1 - > drivers/crypto/ccp/ccp_dev.h | 2 +- > drivers/crypto/cnxk/cn10k_ipsec.c | 2 +- > drivers/crypto/cnxk/cn9k_ipsec.c | 2 +- > .../crypto/cnxk/cnxk_cryptodev_capabilities.c | 2 +- > drivers/crypto/cnxk/cnxk_cryptodev_sec.c | 2 +- > drivers/crypto/nitrox/nitrox_sym_reqmgr.c | 2 +- > drivers/crypto/octeontx/otx_cryptodev.c | 1 - > .../crypto/octeontx/otx_cryptodev_hw_access.c | 2 +- > .../crypto/octeontx/otx_cryptodev_hw_access.h | 2 +- > drivers/crypto/octeontx/otx_cryptodev_ops.h | 2 +- > .../crypto/octeontx2/otx2_cryptodev_mbox.c | 2 +- > drivers/crypto/scheduler/scheduler_failover.c | 2 +- > .../crypto/scheduler/scheduler_multicore.c | 2 +- > .../scheduler/scheduler_pkt_size_distr.c | 2 +- > .../crypto/scheduler/scheduler_roundrobin.c | 2 +- > drivers/event/cnxk/cnxk_eventdev.h | 2 +- > drivers/event/dpaa/dpaa_eventdev.c | 2 +- > drivers/event/dpaa2/dpaa2_eventdev.c | 2 +- > drivers/event/octeontx/ssovf_evdev.c | 2 +- > .../event/octeontx2/otx2_evdev_crypto_adptr.c | 2 +- > lib/cryptodev/cryptodev_pmd.c | 51 +++ > lib/cryptodev/cryptodev_pmd.h | 82 +++- > lib/cryptodev/meson.build | 4 +- > lib/cryptodev/rte_cryptodev.c | 50 ++- > lib/cryptodev/rte_cryptodev.h | 367 +++++++----------- > lib/cryptodev/rte_cryptodev_core.h | 62 +++ > lib/cryptodev/version.map | 7 +- > 28 files changed, 398 insertions(+), 265 deletions(-) > create mode 100644 lib/cryptodev/rte_cryptodev_core.h > > -- > 2.25.1
Hi Akhil, Just ran a quick mutli process test against the patch set, unfortunately it failed on the secondary process enqueue or dequeue. USER1: Configuring vector 0, using session 0 USER1: Start enqueuing packets on dev 0 qp 0 USER1: Start dequeuing packets on dev 0 qp 0 USER1: Enqueuing - Dequeueing -Segmentation fault (core dumped) It will happen on any PMD type. Regards Kai > -----Original Message----- > From: dev <dev-bounces@dpdk.org> On Behalf Of Zhang, Roy Fan > Sent: Monday, October 11, 2021 5:03 PM > To: Akhil Goyal <gakhil@marvell.com>; dev@dpdk.org > Cc: thomas@monjalon.net; david.marchand@redhat.com; > hemant.agrawal@nxp.com; anoobj@marvell.com; De Lara Guarch, Pablo > <pablo.de.lara.guarch@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>; > Doherty, Declan <declan.doherty@intel.com>; matan@nvidia.com; > g.singh@nxp.com; jianjay.zhou@huawei.com; asomalap@amd.com; > ruifeng.wang@arm.com; Ananyev, Konstantin > <konstantin.ananyev@intel.com>; Nicolau, Radu <radu.nicolau@intel.com>; > ajit.khaparde@broadcom.com; rnagadheeraj@marvell.com; > adwivedi@marvell.com; Power, Ciara <ciara.power@intel.com> > Subject: Re: [dpdk-dev] [PATCH v2 0/5] cryptodev: hide internal structures > > Hi Akhil, > > The approach looks great but we may have to check if it works in multi- > process environment - since all enqueue/dequeue handlers are set by > primary process the secondary process may not recognize the fp_ops data. > > We will run a quick test to see if it is true. > > Regards, > Fan > > > -----Original Message----- > > From: Akhil Goyal <gakhil@marvell.com> > > Sent: Monday, October 11, 2021 1:43 PM > > To: dev@dpdk.org > > Cc: thomas@monjalon.net; david.marchand@redhat.com; > > hemant.agrawal@nxp.com; anoobj@marvell.com; De Lara Guarch, Pablo > > <pablo.de.lara.guarch@intel.com>; Trahe, Fiona > > <fiona.trahe@intel.com>; Doherty, Declan <declan.doherty@intel.com>; > > matan@nvidia.com; g.singh@nxp.com; Zhang, Roy Fan > > <roy.fan.zhang@intel.com>; jianjay.zhou@huawei.com; > asomalap@amd.com; > > ruifeng.wang@arm.com; Ananyev, Konstantin > > <konstantin.ananyev@intel.com>; Nicolau, Radu > > <radu.nicolau@intel.com>; ajit.khaparde@broadcom.com; > > rnagadheeraj@marvell.com; adwivedi@marvell.com; Power, Ciara > > <ciara.power@intel.com>; Akhil Goyal <gakhil@marvell.com> > > Subject: [PATCH v2 0/5] cryptodev: hide internal structures > > > > Structures rte_cryptodev and rte_cryptodev_data are not supposed to be > > directly used by the application. These are made public as they are > > used by inline datapath public APIs. > > This patchset, creates a new rte_cryptodev_core.h file which helps in > > defining a data structure to hold datapath APIs in a flat array based > > on the device identifier which is filled by the PMD. > > > > Similar series for ethdev and eventdev are also floated on ML. > > https://patchwork.dpdk.org/project/dpdk/list/?series=19428 > > https://patchwork.dpdk.org/project/dpdk/list/?series=19405 > > > > changes in v2: align with the latest versions of above series. > > > > Akhil Goyal (5): > > cryptodev: separate out internal structures > > cryptodev: allocate max space for internal qp array > > cryptodev: move inline APIs into separate structure > > cryptodev: update fast path APIs to use new flat array > > cryptodev: move device specific structures > > > > drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 1 - > > drivers/crypto/ccp/ccp_dev.h | 2 +- > > drivers/crypto/cnxk/cn10k_ipsec.c | 2 +- > > drivers/crypto/cnxk/cn9k_ipsec.c | 2 +- > > .../crypto/cnxk/cnxk_cryptodev_capabilities.c | 2 +- > > drivers/crypto/cnxk/cnxk_cryptodev_sec.c | 2 +- > > drivers/crypto/nitrox/nitrox_sym_reqmgr.c | 2 +- > > drivers/crypto/octeontx/otx_cryptodev.c | 1 - > > .../crypto/octeontx/otx_cryptodev_hw_access.c | 2 +- > > .../crypto/octeontx/otx_cryptodev_hw_access.h | 2 +- > > drivers/crypto/octeontx/otx_cryptodev_ops.h | 2 +- > > .../crypto/octeontx2/otx2_cryptodev_mbox.c | 2 +- > > drivers/crypto/scheduler/scheduler_failover.c | 2 +- > > .../crypto/scheduler/scheduler_multicore.c | 2 +- > > .../scheduler/scheduler_pkt_size_distr.c | 2 +- > > .../crypto/scheduler/scheduler_roundrobin.c | 2 +- > > drivers/event/cnxk/cnxk_eventdev.h | 2 +- > > drivers/event/dpaa/dpaa_eventdev.c | 2 +- > > drivers/event/dpaa2/dpaa2_eventdev.c | 2 +- > > drivers/event/octeontx/ssovf_evdev.c | 2 +- > > .../event/octeontx2/otx2_evdev_crypto_adptr.c | 2 +- > > lib/cryptodev/cryptodev_pmd.c | 51 +++ > > lib/cryptodev/cryptodev_pmd.h | 82 +++- > > lib/cryptodev/meson.build | 4 +- > > lib/cryptodev/rte_cryptodev.c | 50 ++- > > lib/cryptodev/rte_cryptodev.h | 367 +++++++----------- > > lib/cryptodev/rte_cryptodev_core.h | 62 +++ > > lib/cryptodev/version.map | 7 +- > > 28 files changed, 398 insertions(+), 265 deletions(-) create mode > > 100644 lib/cryptodev/rte_cryptodev_core.h > > > > -- > > 2.25.1
Hi Kai and Akhil, Thanks Kai for finding the problem. To resolve the seg fault for multi-process and keep the structure private, Instead of creating the fp_ops we may ditch making rte_cryptodev_enqueue_burst() and rte_cryptodev_dequeue_burst() inline, and keep everything else as it was? To me these inlines looks not very useful on performance wise anyway. Regards, Fan > -----Original Message----- > From: Ji, Kai <kai.ji@intel.com> > Sent: Monday, October 11, 2021 6:07 PM > To: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Akhil Goyal > <gakhil@marvell.com>; dev@dpdk.org > Cc: thomas@monjalon.net; david.marchand@redhat.com; > hemant.agrawal@nxp.com; anoobj@marvell.com; De Lara Guarch, Pablo > <pablo.de.lara.guarch@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>; > Doherty, Declan <declan.doherty@intel.com>; matan@nvidia.com; > g.singh@nxp.com; jianjay.zhou@huawei.com; asomalap@amd.com; > ruifeng.wang@arm.com; Ananyev, Konstantin > <konstantin.ananyev@intel.com>; Nicolau, Radu <radu.nicolau@intel.com>; > ajit.khaparde@broadcom.com; rnagadheeraj@marvell.com; > adwivedi@marvell.com; Power, Ciara <ciara.power@intel.com> > Subject: RE: [PATCH v2 0/5] cryptodev: hide internal structures > > Hi Akhil, > > Just ran a quick mutli process test against the patch set, unfortunately it > failed on the secondary process enqueue or dequeue. > > USER1: Configuring vector 0, using session 0 > USER1: Start enqueuing packets on dev 0 qp 0 > USER1: Start dequeuing packets on dev 0 qp 0 > USER1: Enqueuing - Dequeueing -Segmentation fault (core dumped) > > It will happen on any PMD type. > > Regards > > Kai > > > > -----Original Message----- > > From: dev <dev-bounces@dpdk.org> On Behalf Of Zhang, Roy Fan > > Sent: Monday, October 11, 2021 5:03 PM > > To: Akhil Goyal <gakhil@marvell.com>; dev@dpdk.org > > Cc: thomas@monjalon.net; david.marchand@redhat.com; > > hemant.agrawal@nxp.com; anoobj@marvell.com; De Lara Guarch, Pablo > > <pablo.de.lara.guarch@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>; > > Doherty, Declan <declan.doherty@intel.com>; matan@nvidia.com; > > g.singh@nxp.com; jianjay.zhou@huawei.com; asomalap@amd.com; > > ruifeng.wang@arm.com; Ananyev, Konstantin > > <konstantin.ananyev@intel.com>; Nicolau, Radu > <radu.nicolau@intel.com>; > > ajit.khaparde@broadcom.com; rnagadheeraj@marvell.com; > > adwivedi@marvell.com; Power, Ciara <ciara.power@intel.com> > > Subject: Re: [dpdk-dev] [PATCH v2 0/5] cryptodev: hide internal structures > > > > Hi Akhil, > > > > The approach looks great but we may have to check if it works in multi- > > process environment - since all enqueue/dequeue handlers are set by > > primary process the secondary process may not recognize the fp_ops data. > > > > We will run a quick test to see if it is true. > > > > Regards, > > Fan > > > > > -----Original Message----- > > > From: Akhil Goyal <gakhil@marvell.com> > > > Sent: Monday, October 11, 2021 1:43 PM > > > To: dev@dpdk.org > > > Cc: thomas@monjalon.net; david.marchand@redhat.com; > > > hemant.agrawal@nxp.com; anoobj@marvell.com; De Lara Guarch, Pablo > > > <pablo.de.lara.guarch@intel.com>; Trahe, Fiona > > > <fiona.trahe@intel.com>; Doherty, Declan <declan.doherty@intel.com>; > > > matan@nvidia.com; g.singh@nxp.com; Zhang, Roy Fan > > > <roy.fan.zhang@intel.com>; jianjay.zhou@huawei.com; > > asomalap@amd.com; > > > ruifeng.wang@arm.com; Ananyev, Konstantin > > > <konstantin.ananyev@intel.com>; Nicolau, Radu > > > <radu.nicolau@intel.com>; ajit.khaparde@broadcom.com; > > > rnagadheeraj@marvell.com; adwivedi@marvell.com; Power, Ciara > > > <ciara.power@intel.com>; Akhil Goyal <gakhil@marvell.com> > > > Subject: [PATCH v2 0/5] cryptodev: hide internal structures > > > > > > Structures rte_cryptodev and rte_cryptodev_data are not supposed to > be > > > directly used by the application. These are made public as they are > > > used by inline datapath public APIs. > > > This patchset, creates a new rte_cryptodev_core.h file which helps in > > > defining a data structure to hold datapath APIs in a flat array based > > > on the device identifier which is filled by the PMD. > > > > > > Similar series for ethdev and eventdev are also floated on ML. > > > https://patchwork.dpdk.org/project/dpdk/list/?series=19428 > > > https://patchwork.dpdk.org/project/dpdk/list/?series=19405 > > > > > > changes in v2: align with the latest versions of above series. > > > > > > Akhil Goyal (5): > > > cryptodev: separate out internal structures > > > cryptodev: allocate max space for internal qp array > > > cryptodev: move inline APIs into separate structure > > > cryptodev: update fast path APIs to use new flat array > > > cryptodev: move device specific structures > > > > > > drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 1 - > > > drivers/crypto/ccp/ccp_dev.h | 2 +- > > > drivers/crypto/cnxk/cn10k_ipsec.c | 2 +- > > > drivers/crypto/cnxk/cn9k_ipsec.c | 2 +- > > > .../crypto/cnxk/cnxk_cryptodev_capabilities.c | 2 +- > > > drivers/crypto/cnxk/cnxk_cryptodev_sec.c | 2 +- > > > drivers/crypto/nitrox/nitrox_sym_reqmgr.c | 2 +- > > > drivers/crypto/octeontx/otx_cryptodev.c | 1 - > > > .../crypto/octeontx/otx_cryptodev_hw_access.c | 2 +- > > > .../crypto/octeontx/otx_cryptodev_hw_access.h | 2 +- > > > drivers/crypto/octeontx/otx_cryptodev_ops.h | 2 +- > > > .../crypto/octeontx2/otx2_cryptodev_mbox.c | 2 +- > > > drivers/crypto/scheduler/scheduler_failover.c | 2 +- > > > .../crypto/scheduler/scheduler_multicore.c | 2 +- > > > .../scheduler/scheduler_pkt_size_distr.c | 2 +- > > > .../crypto/scheduler/scheduler_roundrobin.c | 2 +- > > > drivers/event/cnxk/cnxk_eventdev.h | 2 +- > > > drivers/event/dpaa/dpaa_eventdev.c | 2 +- > > > drivers/event/dpaa2/dpaa2_eventdev.c | 2 +- > > > drivers/event/octeontx/ssovf_evdev.c | 2 +- > > > .../event/octeontx2/otx2_evdev_crypto_adptr.c | 2 +- > > > lib/cryptodev/cryptodev_pmd.c | 51 +++ > > > lib/cryptodev/cryptodev_pmd.h | 82 +++- > > > lib/cryptodev/meson.build | 4 +- > > > lib/cryptodev/rte_cryptodev.c | 50 ++- > > > lib/cryptodev/rte_cryptodev.h | 367 +++++++----------- > > > lib/cryptodev/rte_cryptodev_core.h | 62 +++ > > > lib/cryptodev/version.map | 7 +- > > > 28 files changed, 398 insertions(+), 265 deletions(-) create mode > > > 100644 lib/cryptodev/rte_cryptodev_core.h > > > > > > -- > > > 2.25.1
Hi Akhil, > Structures rte_cryptodev and rte_cryptodev_data are not > supposed to be directly used by the application. These > are made public as they are used by inline datapath > public APIs. > This patchset, creates a new rte_cryptodev_core.h file > which helps in defining a data structure to hold datapath > APIs in a flat array based on the device identifier which > is filled by the PMD. > > Similar series for ethdev and eventdev are also floated on ML. > https://patchwork.dpdk.org/project/dpdk/list/?series=19428 > https://patchwork.dpdk.org/project/dpdk/list/?series=19405 > > changes in v2: align with the latest versions of above series. Just to let you know this patch set causes to seg-fault ipsec-secgw: examples/ipsec-secgw/test/run_test.sh -46m ... [23695833.390785] dpdk-ipsec-secg[2491066]: segfault at 0 ip 0000564325730963 sp 00007fffb9111d00 error 4 in dpdk-ipsec-secgw[564324df0000+134d000] [23695833.390791] Code: 28 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 1f 00 4c 8d 04 cd 00 00 00 00 49 89 ce 4c 89 e7 4a 8d 34 00 48 8b 46 08 48 89 74 24 18 <48> 8b 08 48 89 88 80 00 00 00 f0 83 44 24 80 00 4c 8b 2e 4d 85 ed So far, I didn't dig into it any further. Will have a closer look at Monday. Konstantin > > Akhil Goyal (5): > cryptodev: separate out internal structures > cryptodev: allocate max space for internal qp array > cryptodev: move inline APIs into separate structure > cryptodev: update fast path APIs to use new flat array > cryptodev: move device specific structures > > drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 1 - > drivers/crypto/ccp/ccp_dev.h | 2 +- > drivers/crypto/cnxk/cn10k_ipsec.c | 2 +- > drivers/crypto/cnxk/cn9k_ipsec.c | 2 +- > .../crypto/cnxk/cnxk_cryptodev_capabilities.c | 2 +- > drivers/crypto/cnxk/cnxk_cryptodev_sec.c | 2 +- > drivers/crypto/nitrox/nitrox_sym_reqmgr.c | 2 +- > drivers/crypto/octeontx/otx_cryptodev.c | 1 - > .../crypto/octeontx/otx_cryptodev_hw_access.c | 2 +- > .../crypto/octeontx/otx_cryptodev_hw_access.h | 2 +- > drivers/crypto/octeontx/otx_cryptodev_ops.h | 2 +- > .../crypto/octeontx2/otx2_cryptodev_mbox.c | 2 +- > drivers/crypto/scheduler/scheduler_failover.c | 2 +- > .../crypto/scheduler/scheduler_multicore.c | 2 +- > .../scheduler/scheduler_pkt_size_distr.c | 2 +- > .../crypto/scheduler/scheduler_roundrobin.c | 2 +- > drivers/event/cnxk/cnxk_eventdev.h | 2 +- > drivers/event/dpaa/dpaa_eventdev.c | 2 +- > drivers/event/dpaa2/dpaa2_eventdev.c | 2 +- > drivers/event/octeontx/ssovf_evdev.c | 2 +- > .../event/octeontx2/otx2_evdev_crypto_adptr.c | 2 +- > lib/cryptodev/cryptodev_pmd.c | 51 +++ > lib/cryptodev/cryptodev_pmd.h | 82 +++- > lib/cryptodev/meson.build | 4 +- > lib/cryptodev/rte_cryptodev.c | 50 ++- > lib/cryptodev/rte_cryptodev.h | 367 +++++++----------- > lib/cryptodev/rte_cryptodev_core.h | 62 +++ > lib/cryptodev/version.map | 7 +- > 28 files changed, 398 insertions(+), 265 deletions(-) > create mode 100644 lib/cryptodev/rte_cryptodev_core.h > > -- > 2.25.1
> > Just to let you know this patch set causes to seg-fault ipsec-secgw: > examples/ipsec-secgw/test/run_test.sh -46m > ... > [23695833.390785] dpdk-ipsec-secg[2491066]: segfault at 0 ip > 0000564325730963 sp 00007fffb9111d00 error 4 in dpdk-ipsec- > secgw[564324df0000+134d000] > [23695833.390791] Code: 28 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 1f 00 4c 8d 04 > cd 00 00 00 00 49 89 ce 4c 89 e7 4a 8d 34 00 48 8b 46 08 48 89 74 24 18 <48> > 8b 08 48 89 88 80 00 00 00 f0 83 44 24 80 00 4c 8b 2e 4d 85 ed > > So far, I didn't dig into it any further. > Will have a closer look at Monday. > Thanks for the update, planning to send a next version to fix the multi process issue Reported by Fan, will look into the ipsec-secgw also over weekend.
> > > > Just to let you know this patch set causes to seg-fault ipsec-secgw: > > examples/ipsec-secgw/test/run_test.sh -46m > > ... > > [23695833.390785] dpdk-ipsec-secg[2491066]: segfault at 0 ip > > 0000564325730963 sp 00007fffb9111d00 error 4 in dpdk-ipsec- > > secgw[564324df0000+134d000] > > [23695833.390791] Code: 28 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 1f 00 4c 8d 04 > > cd 00 00 00 00 49 89 ce 4c 89 e7 4a 8d 34 00 48 8b 46 08 48 89 74 24 18 <48> > > 8b 08 48 89 88 80 00 00 00 f0 83 44 24 80 00 4c 8b 2e 4d 85 ed > > > > So far, I didn't dig into it any further. > > Will have a closer look at Monday. > > > Thanks for the update, planning to send a next version to fix the multi process issue > Reported by Fan, will look into the ipsec-secgw also over weekend. As FYI: don't see such problem with v3. In fact, ipsec-secgw functional tests passed with v3 on my box.