From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8DD0245CC3 for ; Thu, 14 Nov 2024 21:16:52 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 817A442EBB; Thu, 14 Nov 2024 21:16:52 +0100 (CET) Received: from fout-a2-smtp.messagingengine.com (fout-a2-smtp.messagingengine.com [103.168.172.145]) by mails.dpdk.org (Postfix) with ESMTP id B86AE4027E for ; Thu, 14 Nov 2024 21:16:50 +0100 (CET) Received: from phl-compute-04.internal (phl-compute-04.phl.internal [10.202.2.44]) by mailfout.phl.internal (Postfix) with ESMTP id 39B391380540; Thu, 14 Nov 2024 15:16:50 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Thu, 14 Nov 2024 15:16:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1731615410; x=1731701810; bh=gwnC52MWgkLVEczOB5YLsiI6MkDYFPaHM22hvUv1nOc=; b= DdBHtmmMQyM1SSBVEvQZ2fgKoE3elbYiZjUii/HVdG8mRN58VjpAiGF3Il97NY4u moyAkNs5CULaiMAEjopnMSAvuLiMl0kTb6a/Tk2Ozr5b91H5F1Pn6f8uiZb5Bypt NuURqx/R+zA+WcYQlhiBwBB8DXzVW+3kEwWpDODoN9MbjwnlClJl4uUw/K7G0Kgk pq3zOC2tkmQgwhk98F8w4XEhpSdvJUejOaCHP6iWEzSmuuluwkfmL0opN5ksOeA7 fKsprC/iOLEFi+M3L+1+P7dMlA9cV/dDa76VtI3OrUXITjDJa2usCVm7XTYbH2ne e1Mib9hlZahxrA/vrsnjlQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1731615410; x= 1731701810; bh=gwnC52MWgkLVEczOB5YLsiI6MkDYFPaHM22hvUv1nOc=; b=g 9nYI97OoNC5jp8JBkUhpuXFLFWGKS0o+QdERotq6TwDPV+v0CcEwAJFqG94QUEYk D/HXYD62KL5GC/BRo7tRlZusIJSOSFRCPd90ehKzaRjHCNzK3ZChkcMf26Q9doNV Mqx8p4CQZPjsq1Vslz12lxzra/dz8tRsw+rIGRXD0DEehGXgTjIKif5aShAVY7ih K4aD7PTLyr55ya+8G2njB22zdpGQnJYovbu77fXvIe4oENuFUis28c8aVZu1ZnG+ FirbaPbmgNZw1SyGgiSSw+ZzhRpfJ01n0y1vHmJMr3O0CTDKHDi9xuuB2e3yR1ON cFTJJeInDkYFqsdOUWD8A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrvddvgddufeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhephffvvefufffkjghfggfgtgesthfuredttddtjeen ucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrg hlohhnrdhnvghtqeenucggtffrrghtthgvrhhnpeekfeehfedtgedtjeehueeutdfgleef ieevkeeikeelkefflefgtdevieehheffudenucffohhmrghinhepughpughkrdhorhhgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhm rghssehmohhnjhgrlhhonhdrnhgvthdpnhgspghrtghpthhtohepgedpmhhouggvpehsmh htphhouhhtpdhrtghpthhtoheptghjsegtjhdrghihpdhrtghpthhtohephigrshhuudel jeeisehgmhgrihhlrdgtohhmpdhrtghpthhtohepuhhsvghrshesughpughkrdhorhhgpd hrtghpthhtohepughsohhsnhhofihskhhisehnvhhiughirgdrtghomh X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 14 Nov 2024 15:16:49 -0500 (EST) From: Thomas Monjalon To: CJ Sculti Cc: Yasuhiro Ohara , users@dpdk.org, Dariusz Sosnowski Subject: Re: DPDK with Mellanox ConnectX-5, complaining about mlx5_eth? Date: Thu, 14 Nov 2024 21:16:36 +0100 Message-ID: <2965041.e9J7NaK4W3@thomas> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org 14/11/2024 17:10, CJ Sculti: > I figured out the initial issue. For some reason, having both devices in a > bond on the kernel results in only 1 of the two ports being exposed as > 'verb' devices. Previously, ibv_devinfo returned only one port. After > removing both from the bond, ibv_devinfo returns both ports, and the DPDK > application successfully takes both in. I'm still having some weird > behavior trying to create a bypass interface with these ports though. I'm > using the same code that I've been using on my Intel NICs with igb_uio for > years, but seeing weird behavior. The ports are connected to our 40Gbps > Ethernet switch, and set to link_layer: Ethernet. You should be able to make it work with kernel bonding, but I'm not sure what's wrong to do that. And it looks not a priority for you. Let's focus on the other parts. > The first thing I noticed is that rte_eth_dev_reset() fails on these > interfaces with "ENOTSUP: hardware doesn't support reset". You don't need the reset procedure with mlx5, so you can make this code optional. > Secondly, when checking ptypes, I noticed my code says these NICs are > unable to support any sort of packet detection capability (code below, all > return false). The MLX5 docs do say that all of these ptypes used here are > supported by MLX5. The supported ptypes can be checked in mlx5_dev_supported_ptypes_get() code. I don't understand why it does not work for you. > I'm just picking up a project that was left off by an older dev. It hasn't > been touched in years, but has been working fine with our Intel NICs. All > I'm trying to do is update DPDK (which is done, updated from dpdk 19.05 to > DPDK 22.11, latest version with KNI support), You don't need KNI with mlx5. That's a big benefit of mlx5 design, it is natively bifurcated: https://doc.dpdk.org/guides/howto/flow_bifurcation.html > and get it to work with our Mellanox CX5 NICs. > This is my first time working with DPDK and I'm not very > familiar. Should I expect to be able to do this without having to make a > ton of code changes, or is this going to be an uphill battle for me? If > it's the latter, I will likely just go purchase Intel NICs and give up on > this. The NICs have difference that DPDK is trying to hide. If something is not compatible you may consider it as a bug or a limitation. I think you should try a bit more, we are here to help.