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 E66F1A05D3 for ; Fri, 24 May 2019 19:05:26 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 961721DB9; Fri, 24 May 2019 19:05:25 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 1031414EC for ; Fri, 24 May 2019 19:05:24 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 92AB721FFD; Fri, 24 May 2019 13:05:23 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 24 May 2019 13:05:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=BWCxVzPG3s/97qtN+nweIX7cEQOViYuyzMcfbDr+5is=; b=jHk54pYDFPuv CiiNYoLS0iTC2UCSeizwCwOWRnZHbihzljxwU5YP83Clb99p4QV7QUPY/eszO/Mp PMrvokQfpdoARu+1D6D3vd3SzVq1YRPYKYiTjFt5+FEhpcGyBnO7rzLTj1UZi2xL 1M48ePRvoWj5b7wTxC+GIp+qgiQuTkA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=BWCxVzPG3s/97qtN+nweIX7cEQOViYuyzMcfbDr+5 is=; b=clDazRYfllhuEhhHCYg22qAOMAgMhiki/f6cT6wA/q/3D5b9l1cbHONPI rjMQSE257bk0mllxFwmA/kazVqGSexEGSeCbSDKSCmfWlfBUmOVXUaDByVKhOr9f C7irOrM0UKRwix3l6MIHYWfouRcXFaTHj7gU1vILVa8INfChqG39l8jCAbGLlmL0 L4MRsA1s/r29tHiIQiEUtwBOrWiEqUB7G+MkO/l4vjXFyYyDjgHruJulUwTpVVWw tknx6CRVVkQpuasrUBTXskqGpvD2Z5jBolVibQ18PvRFXg2XmdZVaPm+kqiHx3eC WmMr9hYreGNFl4gXCv4jcd/wBksNg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudduiedgudduudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc fkphepjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpeht hhhomhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id DE3B4380084; Fri, 24 May 2019 13:05:21 -0400 (EDT) From: Thomas Monjalon To: Stephen Hemminger Cc: dev@dpdk.org, Ferruh Yigit , matan@mellanox.com, Stephen Hemminger Date: Fri, 24 May 2019 19:05:20 +0200 Message-ID: <2341346.KjBqQsXUje@xps> In-Reply-To: <20190524094812.1d4aba4c@hermes.lan> References: <20190523220124.18818-1-stephen@networkplumber.org> <11553980.mcJyG3iUic@xps> <20190524094812.1d4aba4c@hermes.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 24/05/2019 18:48, Stephen Hemminger: > On Fri, 24 May 2019 18:38:53 +0200 > Thomas Monjalon wrote: > > 24/05/2019 18:07, Stephen Hemminger: > > > On Fri, 24 May 2019 14:26:40 +0100 > > > Ferruh Yigit wrote: > > > > > > > On 5/23/2019 11:01 PM, Stephen Hemminger wrote: > > > > > Several users have run into problems where the MLX drivers were not > > > > > enabled in their build. And then trying to run their DPDK > > > > > application on Azure. What happens is that all packets > > > > > go over the slow path, and failsafe repeatedly probes for never > > > > > existing sub-device. > > > > > > > > > > Both Mellanox drivers should be checked. MLX4 for current versions, > > > > > and MLX5 for future upgrades. This code is only called if Hyper-V/Azure > > > > > is detected. > > > > > > > > > > Signed-off-by: Stephen Hemminger > > > > > --- > > > > > drivers/net/vdev_netvsc/vdev_netvsc.c | 7 +++++++ > > > > > 1 file changed, 7 insertions(+) > > > > > > > > > > diff --git a/drivers/net/vdev_netvsc/vdev_netvsc.c b/drivers/net/vdev_netvsc/vdev_netvsc.c > > > > > index 801f54c96e01..64f9dbf66e18 100644 > > > > > --- a/drivers/net/vdev_netvsc/vdev_netvsc.c > > > > > +++ b/drivers/net/vdev_netvsc/vdev_netvsc.c > > > > > @@ -812,6 +812,13 @@ vdev_netvsc_scan_callback(__rte_unused void *arg) > > > > > struct rte_devargs *devargs; > > > > > struct rte_bus *vbus = rte_bus_find_by_name("vdev"); > > > > > > > > > > +#ifndef RTE_LIBRTE_MLX4_PMD > > > > > + DRV_LOG(WARNING, "Mellanox MLX4 not configured."); > > > > > +#endif > > > > > +#ifndef RTE_LIBRTE_MLX5_PMD > > > > > + DRV_LOG(WARNING, "Mellanox MLX5 not configured."); > > > > > +#endif > > > > > > > > Is it OK a virtual PMD being this much aware of another PMD? > > > > Can it be an option to add this check into build system? And if there is direct > > > > dependency perhaps even don't compile the 'vdev_netvsc' when none mlx PMD is > > > > enabled. > > > > > > vdev_netvsc is not a device, it is really just a hack to start other > > > 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.