From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 36434A0AC5 for ; Mon, 27 May 2019 16:54:14 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0352EA49; Mon, 27 May 2019 16:54:13 +0200 (CEST) Received: from mail-pf1-f195.google.com (mail-pf1-f195.google.com [209.85.210.195]) by dpdk.org (Postfix) with ESMTP id 57F393DC for ; Mon, 27 May 2019 16:54:11 +0200 (CEST) Received: by mail-pf1-f195.google.com with SMTP id b76so9709209pfb.5 for ; Mon, 27 May 2019 07:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Lmv+v32t88rR1ZYaszbjO7rxbGeKjAr51flp0FRDy1Y=; b=vDFgcQCBAtlA9H7LWzqm+LLXgWS+IzaqiE8FdZ7kNIOmps29wM1Oo+NxqUWmKUOxXq 7vcmy1cCg9JMangSVhgnO3BDO6RJ/SHrICy92Fr70GUFGi5zVja+dgdzD8I05iZ8srlG 7GTGYa1QxQbMYuo6D0rtMoVfUfBdxjWZiWLPN4Mj293TwT05Ip31WYH/vLUv/fTu6nZi a+f8fLYrw/q2g4rEW/wr3jgsOKfOvzlwcgbP7JJiAetWOz1tPEk9Q4qRuzTI3gLxJDlS JSOpUijPRXINvxvzmHx186FVZYyyAyyHa49p/4Da/UorCmd4bPjYvvn9UqB770GxBNjL 4khQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Lmv+v32t88rR1ZYaszbjO7rxbGeKjAr51flp0FRDy1Y=; b=fmhgHDcoaGGJp6AlsnUUwXplp853eRjjyaOfdbwafOukWtxIk2awKNc7JHMZZ9R3ur pDMLVRmz958RwcJ4eJ+jg1WjUDZiwv6/9cLSB1cLn1hQ1j9gP1gbZQfZo5YHwXmSvNLR Gc4bgwDOXWRFcPcDgr7o2Xlh+MyuvLtgTFhB6TKSfdDo7QS80BKwqU1zWIwuMMHAqsva oQg0PD/Zg9yLfXQtR7W6DM0ssq6sMQx1kdb6llONZ/K1pQHqObT6kI3YO4ma6ktRSbcs oHJVT/urHzHYkEbMRIk1KbKbfFdGltDD3z3bJ3MoOQzeouPkDmvvvN/iWVcMiycNeG5c iV3w== X-Gm-Message-State: APjAAAW4YRiel7l/3WHUqYvTanSil/I26gSgeQUPSio+mRil74SoN1OT sL8i4AnF2fioymGq1CARG1hriB1RUCg= X-Google-Smtp-Source: APXvYqyOxsesXo33IgnwaLvLK3q+1vTe7/gTZldAEIRCrjhrcwCrTKaW6dABXJ/PAsa8LFvCAg53bw== X-Received: by 2002:a63:1316:: with SMTP id i22mr128434843pgl.274.1558968850559; Mon, 27 May 2019 07:54:10 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id d13sm12926032pfh.113.2019.05.27.07.54.10 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 27 May 2019 07:54:10 -0700 (PDT) Date: Mon, 27 May 2019 07:54:08 -0700 From: Stephen Hemminger To: Thomas Monjalon Cc: dev@dpdk.org, Ferruh Yigit , matan@mellanox.com, Stephen Hemminger Message-ID: <20190527075408.3e9fb225@hermes.lan> In-Reply-To: <2413717.vlMEc98STl@xps> References: <20190523220124.18818-1-stephen@networkplumber.org> <2097372.dQ5myFMioY@xps> <20190524150617.6b0246ae@hermes.lan> <2413717.vlMEc98STl@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] net/vdev_netvsc: print warning if Mellanox devices are not configured X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Mon, 27 May 2019 10:31:22 +0200 Thomas Monjalon wrote: > 25/05/2019 00:06, Stephen Hemminger: > > On Fri, 24 May 2019 19:32:14 +0200 > > Thomas Monjalon wrote: > > > 24/05/2019 19:11, Stephen Hemminger: > > > > On Fri, 24 May 2019 19:05:20 +0200 > > > > Thomas Monjalon wrote: > > > > > > > > > > > > device drivers on Hyper-V/Azure. If the build system supported dependencies > > > > > > > > (like Linux kbuild) this would not be necessary. Meson only does dynamic dependencies > > > > > > > > so that doesn't help. > > > > > > > > > > > > > > > > This is a warning and not fatal only because application will still at > > > > > > > > least run, and somebody may want to run with SR-IOV with Intel NIC's on Hyper-V. > > > > > > > > > > > > > > > > > > > > > > > > The warning is just to give users better immediate feedback rather than > > > > > > > > trying to diagnose poor performance or mystery device not found messages. > > > > > > > > > > > > > > > > > > > > > It really looks strange to me. > > > > > > > What you need is to fail at compilation if requested PMD is not built. > > > > > > > I would advise to work on a script to configure meson. > > > > > > > > > > > > None of the people that ran into this were using meson build. > > > > > > For example, VPP doesn't use meson. > > > > > > > > > > They will use meson when makefile will be removed :) > > > > > > > > > > Anyway, no matter the build system, what we want is a way > > > > > to guide users to a proper DPDK installation. > > > > > Your solution is to add some very specific logs. > > > > > My proposal is to guide the user with a script and some > > > > > specific parameters so it will fail if a required dependency is not met. > > > > > > > > Not familiar enough with meson magic syntax to make vdev_netvsc not build > > > > without MLX. But that would just be pushing the mystery failure further > > > > down the road. > > > > > > I think you did not understand my proposal. > > > Let's take an example. You give this instruction to build DPDK: > > > buildtools/build-require.sh vdev_netvsc mlx4 > > > > There is no build-require.sh now and introducing yet another tool > > is not going to help. > > I disagree. > I think we are missing this tool. > > > > If mlx4 is not built then it will fail with this message: > > > librte_pmd_mlx4 failed to build > > > So the user knows what went wrong. No mystery. > > > > > > > > > > Another alternative would be to drop vdev_netvsc from the default Linux > > > > build. That way users would have to enable it manually. > > > > > > > > My preferred solution would be to just kill vdev_netvsc and go to only netvsc PMD > > > > but that is a couple releases away. > > > > Let's just fix the meson.build for now to skip vdev_netvsc unless both mlx4 and mlx5 are present. > > This is not a fix but a hack. > Why vdev_netvsc would need mlx PMDs? Because it is the Azure config? MLX is required because no other VF device has been tested. Intel devices barely work (wrong PCI id, and only a single queue). No one has ever tried other vendors.