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 D3B9145D0F for ; Fri, 15 Nov 2024 11:12:05 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AB1A642FB5; Fri, 15 Nov 2024 11:12:05 +0100 (CET) Received: from mail-qv1-f53.google.com (mail-qv1-f53.google.com [209.85.219.53]) by mails.dpdk.org (Postfix) with ESMTP id C9084402EB for ; Fri, 15 Nov 2024 11:12:03 +0100 (CET) Received: by mail-qv1-f53.google.com with SMTP id 6a1803df08f44-6d3f6a548b2so7564226d6.2 for ; Fri, 15 Nov 2024 02:12:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731665523; x=1732270323; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=/Re+pcP3f9bTIR8YOf3dafRigbKnhRrFwhnwrXnXsPg=; b=GswRqtdpoUJYOWXIUTAc/7iKIuWewzOVlw2Kd9imvfcMb5Me/Eo3hGaRs5JbDQIOg+ 1bbNAeSX4E7F5H11bZ137CM8bbiY/HgpKPgNQpOjLidWqdiyxiAxNHPNefVpPG0F1poi 0WdzVc3SxhAr4QYskl8x9Tl+ka2P2Lnqkqfnv8dkrU06iWs45XxPm0UhoyMHMMGoXsoF za6P7l8zzI/1TrjRmhnFnIhKq+0Iiok7YT431+/6oG5Ppt9bS0XX4/IGhDTrZCKsL6En eNBFmmB2qj6YqDzDXMNhPJKTvsRlsilG4P0l0f1JyBlGUamlunJ3P7QKGhoafsSrgkMK PM/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731665523; x=1732270323; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/Re+pcP3f9bTIR8YOf3dafRigbKnhRrFwhnwrXnXsPg=; b=L2qIV5R2GFiC+Rs13tKParH+oO96mHVlxFnluMzPGnL9SxZiexoX189p2pSuO1ARNd Og825uuQTQHBOVTMxPu6NZpmywevEhvNcOQ5sP4HIfHOCCRvgzQIpUY7hzCxJvtNaV9K Ir2A7wa1tp3UQIPVSJ7BCG10Owv/5m8MyMlej0TPtfDG622+kcHknDfD92oJAUYDqqAs u/JnxDFyDCZcmWM+Lfn0qLRlXBWlCxbaeyI1LDRxh3NOXP0JtOg/MsDSDrN0P/AtO4kZ LaTey6nk0ijM5BYTM+XlKiuJ+EY1GLD7Hr9usl31mmhTVpQTgf3Dzr6vbmUibb3qVjvh Yu1w== X-Forwarded-Encrypted: i=1; AJvYcCWrM7+vFSIqb/53zKDKFmQnxUw7d7KxywXAfeWnlO+xf24SaHb87bXO3kpiyJjSr3Cp014PUA==@dpdk.org X-Gm-Message-State: AOJu0YyGzdR9D58XJ/iwyXLM75dsdHoGhVgAhMWR/eJ84mx44qOPr0Z/ Ru+czmLwW681O37Yu4Ct/UvrBVK4HwPp5oAPhb+bkIfxVR3RFmpNwlEWPgTiQH3H0DW8np4jq8v b43MkHdsnvZknCoEmh/9WxZhrUwA= X-Google-Smtp-Source: AGHT+IGPkPMFEZoDsTHhSF/Fet913CukF3s/RnOF/TDnZ1Bk3Q3VLtD9IbeRsa3CCzLBiWI+tsFX6VyC2J0iVcNFoME= X-Received: by 2002:a0c:f20a:0:b0:6d3:f733:7037 with SMTP id 6a1803df08f44-6d3fb7cc0a6mr26528266d6.11.1731665522961; Fri, 15 Nov 2024 02:12:02 -0800 (PST) MIME-Version: 1.0 References: <2965041.e9J7NaK4W3@thomas> In-Reply-To: <2965041.e9J7NaK4W3@thomas> From: Yasuhiro Ohara Date: Fri, 15 Nov 2024 18:11:51 +0800 Message-ID: Subject: Re: DPDK with Mellanox ConnectX-5, complaining about mlx5_eth? To: Thomas Monjalon Cc: CJ Sculti , users@dpdk.org, Dariusz Sosnowski Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 > I think you should try a bit more, we are here to help. I second Thomas's opinion. Mellanox CX5 is a well-tested NIC on DPDK, and I think you can make it work in only a few more steps. I've never tried rte_eth_dev_reset(), and now I suspect that ENOTSUPP might have made the whole NIC functions stopped. IIRC the ptype was working fine on CX5 in my app too. Can you comment out the rte_eth_dev_reset() ? (I think it's worth to try.) I don't think it is so uphill, but I don't disagree with you about purchasing another Intel 40G NICs. It'll also work perfectly fine. 2024=E5=B9=B411=E6=9C=8815=E6=97=A5(=E9=87=91) 4:16 Thomas Monjalon : > > 14/11/2024 17:10, CJ Sculti: > > I figured out the initial issue. For some reason, having both devices i= n 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 DP= DK > > 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() co= de. > 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 has= n't > > been touched in years, but has been working fine with our Intel NICs. A= ll > > 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 limitati= on. > I think you should try a bit more, we are here to help. > >