Message ID | 20171128145855.27106-1-pbhagavatula@caviumnetworks.com (mailing list archive) |
---|---|
State | Superseded, archived |
Delegated to: | Ferruh Yigit |
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 [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 361A82BE9; Tue, 28 Nov 2017 15:59:31 +0100 (CET) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0040.outbound.protection.outlook.com [104.47.32.40]) by dpdk.org (Postfix) with ESMTP id 946891D90 for <dev@dpdk.org>; Tue, 28 Nov 2017 15:59:29 +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=O2HwJT8TQjdf+H3UlqIeiD+JmUyufnrsS5AXYFyQaH4=; b=F3kMtJZNLlqH1zFYHW5b1jnH9qlX67PNiQImj8GJw8KnSHJeIooeKYGsRp0VJP/gTj6b29Gt4EcNL0pKLahXRl6BF0dV9glPq+K440IZWwpCcnQ2iPLQw6WGRJvLpuF39JVqA0P+1elQnJORHvB2/4cHf64603ojVissgR38koY= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Pavan.Bhagavatula@cavium.com; Received: from Pavan-LT.caveonetworks.com (111.93.218.67) by MWHPR07MB3469.namprd07.prod.outlook.com (10.164.192.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Tue, 28 Nov 2017 14:59:26 +0000 From: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com> To: santosh.shukla@caviumnetworks.com, ferruh.yigit@intel.com Cc: dev@dpdk.org, Pavan Nikhilesh <pbhagavatula@caviumnetworks.com> Date: Tue, 28 Nov 2017 20:28:54 +0530 Message-Id: <20171128145855.27106-1-pbhagavatula@caviumnetworks.com> X-Mailer: git-send-email 2.14.1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [111.93.218.67] X-ClientProxiedBy: BM1PR01CA0108.INDPRD01.PROD.OUTLOOK.COM (10.174.208.24) To MWHPR07MB3469.namprd07.prod.outlook.com (10.164.192.20) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e8bc4d05-56d6-4e67-a17d-08d536709f11 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603199); SRVR:MWHPR07MB3469; X-Microsoft-Exchange-Diagnostics: 1; MWHPR07MB3469; 3:gIcb6zhD8S8nCqD4s1lTUgpQc0tKMmDT9KRDujF3Caj1VKOPobRCyTtB2sEsHdZ8QXubL8WBd+5sC1ejxhgPtGDPTnBklMPxlnMfzGle3QtBNGiivJFQGnJIxS83Oj/agffwvB2V0c6oFT8IZoDilQ9KPI8bMX+qLDWgDsiQ3/a/eagC+cVn+fGYhoOcRTLoVuX/qKSh4Yf99LytHfHhT5psP7r5jFjLVI9jxA3SOrUF3vvA+DQxdGrFYeuuRmIn; 25:QXtynl0INKUQIYkUiIkE8B/+mJiyzVOXFc58Oo0PEcHE9Qp3vZz8HZ4qhW9ngJ4bZl0dJiZfcI4VgmJn1HGEmen2M7pbMRVATIMDTm8aOIrw3tXy1nhKLKAq9f+SEblsqkG2LKrzIn91FKzjh8IBQyjsNkfBe/jc/Av8u5rpONk+JSHuAEkPVhh/slZ7P+0hH8AiNM7ct9EQipOnZaXbyGrbPJIBX3Cbi+1RiQz/IxiREyoSaF1LUezMxYXWH1/OFdcD7BkA7AoNX5uz9CmkLLi/M2OK/XhALTjQJjcyuRR4lmIavKahtZq1fFbcdSzhTLFIDLqbb9T58B8Bf9Knhg==; 31:u5NzFTbN8gsqqvGTolnFZ5tijoEmv73RSBD08aNBaR6CXKlNITLnGdQe65w38kD/z5n7ssD972PC5E7rsc7jCT7cz0j40ybolX6nrAfVPngBksGJUWBDywd2J/5PQCssQ0iT9JBksU0snX3bOOU5Kv9VqLWkzuDDWQ07Tu2AqkRD8R+c+YzpjeCSjjocFMxy1RN8No0eszbHF2YcqzKJ2+VQTTaQHTvKHtV1GYmwdT8= X-MS-TrafficTypeDiagnostic: MWHPR07MB3469: X-Microsoft-Exchange-Diagnostics: 1; MWHPR07MB3469; 20:6r2a/t+qrCEwcbfPVmjpGJ8yhsSM1Vdwb9pYLL99quF1RFQLjM0mdwzhmXguE9mXOVdAX5oVB9R93XW+YEHdFf4b0XUco6wjyHGZVeorUOTs3E9Sms0FeLpnYcIZbLg0wl23VX8WDZL4z0qA4krrT3fDkLUD7ophflgOVQDyl/pue8Du21R3Lv2L1DXSDjL6O5LGFZlYP8325aOqvj46hPr++zYv+cOxmTLgMio84IyaoXL3SUcj9sGTQpmgYMKWv8V8lxxn0fo3HCm8EHNa1Z93wKdiMw0ZEe79Gr1zykofjRbtMtHTt0OJt/MeVHG46OSAzeDkOTHy0m5VoZB73AA5Jb0ER2AncSCVJrNbe2OwQhQrLpKBHZpH9EzsxzHQN6QC02K8zWTfqJQoCKfsUO/pepiyQ9/l6IWUB3Tve9XzNva0KMV1s/bDO5qLYAXjE3FAiL7cFmhWi+Jyfcf/twWv3JU23C6C0p9fTZTDddVZmr9cwD1mmxedOxwHmSDVSSl+gdFpeQP3zyvKknactLzRMoAwmDETqKvvRf9pz0lR/9Sct6Cnq+DmSwpWF4wphsylRqenw5Yg+vp6kERWDrTKiiHh/DkBRpoGqWGK2gg=; 4:fMGxu0loFOSy8JNLopg+V6N3KfZ2Pl8dFgGEBZrv0ORViXo5hIiQ8nImJSHptqTaomrPFe5qE9dz5cjWxRKo/sVrhIb+BIQxbrIvIH89gxD2YE+4Eg4pJTtv8MdnmHHmsjx06yQpyabJ/GsDYCWOUtH/HYTCsMxD2dEWNqdNxTUD5SuuGINA19f+7FNY86izDeyLq30jWCUJ9F0aHcR2GIOLnpdLlexZy58+bpTGUtxVsOJ/ns4NGbmHw0sOlalmWfeYhshM1DIZMcXD9C5quQ== X-Microsoft-Antispam-PRVS: <MWHPR07MB3469A7D5CA0B67F6EE33018E803A0@MWHPR07MB3469.namprd07.prod.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3231022)(3002001)(10201501046)(93006095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(6072148)(201708071742011); SRVR:MWHPR07MB3469; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR07MB3469; X-Forefront-PRVS: 0505147DDB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(366004)(346002)(376002)(189002)(199003)(105586002)(4326008)(47776003)(50466002)(6506006)(106356001)(97736004)(72206003)(5009440100003)(478600001)(16586007)(5660300001)(53936002)(42882006)(316002)(8936002)(51416003)(53416004)(189998001)(52116002)(69596002)(6666003)(1076002)(48376002)(68736007)(50986999)(107886003)(50226002)(305945005)(6116002)(3846002)(16526018)(6486002)(66066001)(7736002)(25786009)(2906002)(8676002)(101416001)(81166006)(81156014)(6512007)(33646002)(36756003)(42262002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR07MB3469; H:Pavan-LT.caveonetworks.com; 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: =?us-ascii?Q?1; MWHPR07MB3469; 23:xqjvS7kKekH3NwaJEjlrO4UtMMHlTU/UXf82fxnzN?= TUIdwa18SWKjfs+9gqI+IxC/TnyyyhqU3dBxT9xjeY2OHLo1s2C426dHZqUJCrxaXUX8/GezoihOKVOhXMBIb1/WsvAHnVB4sIPvuBYXipsg9ajI83FAuwlUuQcfMIYSwbNd6WoSbOQnR7n3ZiTsYm0fLit//Z7xRp8KofYd2JZ/Nel0g5GiNDUrvYk5wdTJBKVfHUtZ1+ULQT6Uf6EwIuj32uPXzg/D5y3QU9RnO4fEw91SF2Pkh+0FmmSjtSUr8Ynm0vVZzhxSxVadLqIz5pM+xiVz2cuj1lkR69dJEpA86tOVRzBVmfAEVktndkj7jmMpzxTOakna/bh5aSnpyVy97LJ9gtVtte6rC2TbhxiBb91V6mfT4ylZo4HOcaaXAtve5DR6O1dOsy2ySc5aPqfhWKuMCfnji/W6g1IfcRh8KJLjJ3xU4/uB1xzK1fzXsmvz6o7K+DMIcvFA0Lt8CwP7r15jKz1yV7EmzlsY1Ftyo8Ur/JCbLM8iJaqMp4D0bm6fBjz9Y50Dk/qC6w2IhQTwXGL2A2T76qggrFYQZa2suiinK2lKKxyfCLpFZ2vvfYy12z6IpQA2+TVDMLvEW6xRXuyetiRMUQpe1Xf7crnV163yLUqN7sy/nNutCUtlJxQlTZ7py4hgTdycW7oTmsZceOGyevpbKm4+UHLZBjR806ry7QYzD25AVi6/TP0vn3/TK/fIc3I4l975vfZ/NYG8lv8SPbxv+7tv3MGW+Eowwkv1keGWzWk/TBv2RJc56lng66WtOdrmLQ6n6a/Qcs73kSAY8EJ0gmmKQ9ugtJEYhcyI7nRMbZVwS3FMreMnrCZfrbq9Ov/N/T8U68kz57c8V3CVw28G3P63689hxe8/c2froLSgzwaUF7skpJfk/dnpF1nyx+K4Q2V8/7ADhaT2MbQmCoyKa546oq7Ewp89AYEo2d0ohSQeP62U/IwsophciUbijTD5Fp2ehmCQVJvKiE7M5AVdenZmVNOjY8dw/NIS01gy0Anu8+a5j8quuayYlmLpk5n1Q8HFRZ0KjqMIjcpfMTnu5m7YU1FRl8K8ne2E2oavDWTwjVIufINl4cxL3AH7FL5Zba38SPzk1lSgHpWCdSICbIvXalJ+Z0o5GKKO8UBOw8k7ysXE1Bdmmc= X-Microsoft-Exchange-Diagnostics: 1; MWHPR07MB3469; 6:BNF77RwY8emMeuumDqFXqagsk2KRUo2Jve+fSoEsUxiQG+QORFDhk1RZ+yG+r5Oxx61yB1in14Ox0sYcaWT/2OUjvhvSx3hD3xIqmjhFAN1p2AbjiLc+/AZHRUApSvjOz4WvRSyMUh4J//hC3mg4UjfuLrDZN6/Pf5JnR+hDXop2+D26qCHRMLRIfOUfiB78w7p1liG1J8TOq2qlpG12CRh2/UrvsH2vdke5Tzzp3BJY9fk1A5Hm/ZFZ5eg2ryf7AljSsQpsEx4VKasPAC0M6o5Nli9mxKVVJaLBU8MHPGopUsbjyeBAz2vlN5Pz8Ipj0Q/pnjmqPK8yixywTnk/XuTJoIzPgD1IMvvlWzzf4zk=; 5:bPBC2T9EUHGI7uM2/JjcOploAtoHF/dhv6TYC81wYufQsVGneaOszlFHw3LbReQTbitdbeOfVBQofNECcyos7vKqPN66XMSXr7GE8gezHCZ9PmST5gSkXpuXCI/Lp+iLkabr8la2l6vUQxCXMDtq6EQN6wKWij8YP02hSWhcM6I=; 24:2XCKxvcULoeYTuDiia45TP1uX+lwN2+jzdgkN6ZUvr9+8ik+PJyIJNeB32N8029xShNQSbg2xHhqdsKUK/5U7tROVnIRPemfg61+I/YKnOI=; 7:nVSfWZAx1cfi3KxrqkZBjCJ9DNi7jS8uMxj4NwxnreiDPbmSCNXaBj36xPpJf+ARkcuY/rRz+/ilKVs5ZX89UF/mkUmF+6zq82WXUNrfZlkyCw0eIZXjmFBeMY9At00cCyDUmhJVjpYsAaGBZk85siyKP4fufhhsehmVLMeMeMmzl9R/3S2xdzfo6o+5Q+1EHpxfOo2JCZ9Fx8rwiK3DDVBCNbvRc1pPoqTArelV8M6jFXKdtl9WoVdQE29LD2zT SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Nov 2017 14:59:26.0294 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e8bc4d05-56d6-4e67-a17d-08d536709f11 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR07MB3469 Subject: [dpdk-dev] [PATCH 1/2] net/octeontx: add channel to port id mapping 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
Pavan Nikhilesh
Nov. 28, 2017, 2:58 p.m. UTC
The channel to port id map is used by event octeontx to map the received
wqe to the respective ethdev port.
Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>
---
drivers/net/octeontx/octeontx_ethdev.c | 3 +++
drivers/net/octeontx/octeontx_ethdev.h | 6 ++++++
2 files changed, 9 insertions(+)
Comments
On 11/28/2017 6:58 AM, Pavan Nikhilesh wrote: > The channel to port id map is used by event octeontx to map the received > wqe to the respective ethdev port. > > Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com> <...> > @@ -52,12 +52,18 @@ > #define OCTEONTX_VDEV_NR_PORT_ARG ("nr_port") > #define OCTEONTX_MAX_NAME_LEN 32 > > +#define OCTEONTX_MAX_BGX_PORTS 4 > +#define OCTEONTX_MAX_LMAC_PER_BGX 4 > + > static inline struct octeontx_nic * > octeontx_pmd_priv(struct rte_eth_dev *dev) > { > return dev->data->dev_private; > } > > +uint16_t __rte_cache_aligned > +octeontx_pchan_map[OCTEONTX_MAX_BGX_PORTS][OCTEONTX_MAX_LMAC_PER_BGX]; defining global variable in header is generally not good a idea, is there a reason why not variable defined in octeontx_ethdev.c and exported here, so that both octeontx ethdev and eventdev can use it? btw, is build time dependency between octeontx ethdev and eventdev documented somewhere?
On Thu, Dec 07, 2017 at 04:41:04PM -0800, Ferruh Yigit wrote: > On 11/28/2017 6:58 AM, Pavan Nikhilesh wrote: > > The channel to port id map is used by event octeontx to map the received > > wqe to the respective ethdev port. > > > > Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com> > > <...> > > > @@ -52,12 +52,18 @@ > > #define OCTEONTX_VDEV_NR_PORT_ARG ("nr_port") > > #define OCTEONTX_MAX_NAME_LEN 32 > > > > +#define OCTEONTX_MAX_BGX_PORTS 4 > > +#define OCTEONTX_MAX_LMAC_PER_BGX 4 > > + > > static inline struct octeontx_nic * > > octeontx_pmd_priv(struct rte_eth_dev *dev) > > { > > return dev->data->dev_private; > > } > > > > +uint16_t __rte_cache_aligned > > +octeontx_pchan_map[OCTEONTX_MAX_BGX_PORTS][OCTEONTX_MAX_LMAC_PER_BGX]; > > defining global variable in header is generally not good a idea, is there a > reason why not variable defined in octeontx_ethdev.c and exported here, so that > both octeontx ethdev and eventdev can use it? The reason extern definition in .h and declaration in .c is not done is that it would break shared compilation. The other approach is to do it in octeontx_mempool area but it wouldnt make sense. I could use the mempool approach if it sounds good to you (or) let me know if any alternate approach comes to your mind. > > btw, is build time dependency between octeontx ethdev and eventdev documented > somewhere? Currently, there is no build time dependency between event_octeontx and eth_octeontx i.e everything builds fine with CONFIG_RTE_LIBRTE_OCTEONTX_PMD=n. Thanks, Pavan
On 12/8/2017 3:08 AM, Pavan Nikhilesh Bhagavatula wrote: > On Thu, Dec 07, 2017 at 04:41:04PM -0800, Ferruh Yigit wrote: >> On 11/28/2017 6:58 AM, Pavan Nikhilesh wrote: >>> The channel to port id map is used by event octeontx to map the received >>> wqe to the respective ethdev port. >>> >>> Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com> >> >> <...> >> >>> @@ -52,12 +52,18 @@ >>> #define OCTEONTX_VDEV_NR_PORT_ARG ("nr_port") >>> #define OCTEONTX_MAX_NAME_LEN 32 >>> >>> +#define OCTEONTX_MAX_BGX_PORTS 4 >>> +#define OCTEONTX_MAX_LMAC_PER_BGX 4 >>> + >>> static inline struct octeontx_nic * >>> octeontx_pmd_priv(struct rte_eth_dev *dev) >>> { >>> return dev->data->dev_private; >>> } >>> >>> +uint16_t __rte_cache_aligned >>> +octeontx_pchan_map[OCTEONTX_MAX_BGX_PORTS][OCTEONTX_MAX_LMAC_PER_BGX]; >> >> defining global variable in header is generally not good a idea, is there a >> reason why not variable defined in octeontx_ethdev.c and exported here, so that >> both octeontx ethdev and eventdev can use it? > > The reason extern definition in .h and declaration in .c is not done is that > it would break shared compilation. This should work, you can put object into .so and access from application and/or other shared libraries. I did a quick test, and seems working, is there anything I am missing. > The other approach is to do it in octeontx_mempool area but it wouldnt make > sense. > I could use the mempool approach if it sounds good to you (or) let me know > if any alternate approach comes to your mind. > >> >> btw, is build time dependency between octeontx ethdev and eventdev documented >> somewhere? > > Currently, there is no build time dependency between event_octeontx and > eth_octeontx i.e everything builds fine with CONFIG_RTE_LIBRTE_OCTEONTX_PMD=n. octeontx eventdev is using a variable from octeontx ethdev header, how can be there is no build time dependency? > > Thanks, > Pavan >
On Fri, Dec 08, 2017 at 09:39:00AM -0800, Ferruh Yigit wrote: > On 12/8/2017 3:08 AM, Pavan Nikhilesh Bhagavatula wrote: > > On Thu, Dec 07, 2017 at 04:41:04PM -0800, Ferruh Yigit wrote: > >> On 11/28/2017 6:58 AM, Pavan Nikhilesh wrote: > >>> The channel to port id map is used by event octeontx to map the received > >>> wqe to the respective ethdev port. > >>> > >>> Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com> > >> > >> <...> > >> > >>> @@ -52,12 +52,18 @@ > >>> #define OCTEONTX_VDEV_NR_PORT_ARG ("nr_port") > >>> #define OCTEONTX_MAX_NAME_LEN 32 > >>> > >>> +#define OCTEONTX_MAX_BGX_PORTS 4 > >>> +#define OCTEONTX_MAX_LMAC_PER_BGX 4 > >>> + > >>> static inline struct octeontx_nic * > >>> octeontx_pmd_priv(struct rte_eth_dev *dev) > >>> { > >>> return dev->data->dev_private; > >>> } > >>> > >>> +uint16_t __rte_cache_aligned > >>> +octeontx_pchan_map[OCTEONTX_MAX_BGX_PORTS][OCTEONTX_MAX_LMAC_PER_BGX]; > >> > >> defining global variable in header is generally not good a idea, is there a > >> reason why not variable defined in octeontx_ethdev.c and exported here, so that > >> both octeontx ethdev and eventdev can use it? > > > > The reason extern definition in .h and declaration in .c is not done is that > > it would break shared compilation. > > This should work, you can put object into .so and access from application and/or > other shared libraries. I did a quick test, and seems working, is there anything > I am missing. > > > The other approach is to do it in octeontx_mempool area but it wouldnt make > > sense. > > I could use the mempool approach if it sounds good to you (or) let me know > > if any alternate approach comes to your mind. > > > >> > >> btw, is build time dependency between octeontx ethdev and eventdev documented > >> somewhere? > > > > Currently, there is no build time dependency between event_octeontx and > > eth_octeontx i.e everything builds fine with CONFIG_RTE_LIBRTE_OCTEONTX_PMD=n. > > octeontx eventdev is using a variable from octeontx ethdev header, how can be > there is no build time dependency? > Hi Ferruh, I misread the order in which thing are built. I will send out a v2 with the suggested changes soon. Thanks, Pavan > > > > Thanks, > > Pavan > > >
diff --git a/drivers/net/octeontx/octeontx_ethdev.c b/drivers/net/octeontx/octeontx_ethdev.c index bd24ec330..8e251786b 100644 --- a/drivers/net/octeontx/octeontx_ethdev.c +++ b/drivers/net/octeontx/octeontx_ethdev.c @@ -1133,6 +1133,9 @@ octeontx_create(struct rte_vdev_device *dev, int port, uint8_t evdev, nic->num_tx_queues); PMD_INIT_LOG(DEBUG, "speed %d mtu %d", nic->speed, nic->mtu); + octeontx_pchan_map[(nic->base_ochan >> 8) & 0x7] + [(nic->base_ochan >> 4) & 0xF] = data->port_id; + return data->port_id; err: diff --git a/drivers/net/octeontx/octeontx_ethdev.h b/drivers/net/octeontx/octeontx_ethdev.h index c47d4c6d3..0cff13611 100644 --- a/drivers/net/octeontx/octeontx_ethdev.h +++ b/drivers/net/octeontx/octeontx_ethdev.h @@ -52,12 +52,18 @@ #define OCTEONTX_VDEV_NR_PORT_ARG ("nr_port") #define OCTEONTX_MAX_NAME_LEN 32 +#define OCTEONTX_MAX_BGX_PORTS 4 +#define OCTEONTX_MAX_LMAC_PER_BGX 4 + static inline struct octeontx_nic * octeontx_pmd_priv(struct rte_eth_dev *dev) { return dev->data->dev_private; } +uint16_t __rte_cache_aligned +octeontx_pchan_map[OCTEONTX_MAX_BGX_PORTS][OCTEONTX_MAX_LMAC_PER_BGX]; + /* Octeontx ethdev nic */ struct octeontx_nic { struct rte_eth_dev *dev;