From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 2C89C6CC7 for ; Thu, 19 Apr 2018 11:47:48 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A253721B88; Thu, 19 Apr 2018 05:47:47 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 19 Apr 2018 05:47:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=uAMdotQ8AUYhbBSH+TiJxIOhNH m3jD2ltXF1venj7HQ=; b=ftS0r/+b/xBI10hIk0buLT3Ca2yjDD9NTto1kZffGX fsuDYPo+h/MROa3zCi9DQTm9a/iNT6hhdPq7OjpoW6vCpGqjB15FT2rXiKnLPt4Y ICwJRDVG/mqnkZkR/7YcJI2yNpUgg3RTX5gsR2E48iPljPJVXsrGOLrTGKakPhKW A= 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-sender:x-me-sender:x-sasl-enc; s=fm2; bh=uAMdot Q8AUYhbBSH+TiJxIOhNHm3jD2ltXF1venj7HQ=; b=TpOM9libO4HNz9NYblwuft 2EjsR6OWgbvUjdpuGLxoUvITMwqULGi2HQx72yZd+2/RJCwEW8OYKeVd/yiMTojB mmlEZXLQ3rX5jr1pf/zVTOv0fLmOr0o8IxGWUQBJ99D6/8xKdxdn313fAq9Te1ee g7cuDcppAM5dMBOz55rP0iGWmCRXWvIL2EFfWTk2pnNVoh3H9t5G4KDcYreW5kEJ EdWIrMQBLrCGolGks8QLJf4zB4w9+BoqTRTvoCbdGWv4vZPMkiSWIGe4n/cM6g5I oqxN2o90DeOZlIjK9yvcBAbk5N5Yglus0TswRjnoHXoP4/gcTCqdm5CyxKaeCvRg == X-ME-Sender: Received: from xps.localnet (229.85.136.77.rev.sfr.net [77.136.85.229]) by mail.messagingengine.com (Postfix) with ESMTPA id 9A72910255; Thu, 19 Apr 2018 05:47:43 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson Cc: Alejandro Lucero , Flavio Leitner , Stephen Hemminger , dev , "Burakov, Anatoly" , David Marchand , jia.guo@intel.com, matan@mellanox.com, "Ananyev, Konstantin" Date: Thu, 19 Apr 2018 11:47:40 +0200 Message-ID: <2341963.L53P3Yzpy1@xps> In-Reply-To: <20180419084044.GA11624@bricha3-MOBL.ger.corp.intel.com> References: <2407757.yEAnF6RcS7@xps> <1901154.ialemUER5X@xps> <20180419084044.GA11624@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] kernel binding of devices + hotplug 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: , X-List-Received-Date: Thu, 19 Apr 2018 09:47:48 -0000 19/04/2018 10:40, Bruce Richardson: > On Thu, Apr 19, 2018 at 10:24:24AM +0200, Thomas Monjalon wrote: > > 19/04/2018 08:04, Alejandro Lucero: > > > I do not completely understand the discussion, but I think the > > > disagreement is due to how some devices interact with DPDK, at least > > > Mellanox ones. I'm saying that because we have a DPDK app which starts > > > with no device at all (--no-pci) and it relies on device plugging > > > attach/detach for configuring and removing ports once devices are bound > > > to VFIO or UIO drivers. Maybe I'm wrong, but I think because Mellanox > > > cards do not use VFIO or UIO drivers but some specific bound using > > > verbs inside the PMD, leaving all this binding to the system does not > > > fit them. > > > > Mellanox uses a bifurcated model for any use. Others could use a > > bifurcated model thanks to AF_XDP. That's why it is more correct to > > compare "bifurcated model" vs "UIO/VFIO". > > > > > If that is the case, although I agree with leaving the device binding > > > to the system, I think it would be fair to contemplate a dual approach > > > for legacy reasons, or to leave time for implementing a pseudo system > > > driver which Mellanox can use for having same functionality. > > > > I summarize the comparison: - On one hand, we can configure all the > > devices only once in DPDK, but it gives super-powers to the DPDK > > application. - On the other hand, we can do a part of the setup at > > system level (some kernel binding or flow bifurcation), and we do another > > part of the setup in DPDK, splitting/duplicating the setup info in two > > places. > > > I disagree with this final assessment. If there is duplication, it would > appear more in the former case than in the latter, as the logic for > determining driver binding and ownership would have to be duplicated in > both the kernel and DPDK. Also, there are plenty of instances where the > kernel is going to use the devices without DPDK, so you can't reduce > duplication by putting functionality into DPDK - the kernel is not going to > remove functionality just because DPDK offers it! Therefore, if minimizing > duplication is important to you, the solution to chose is to use as much > from the kernel (and associated utilities like udev) as possible and not > implement it in DPDK. In any case, we need to choose and configure DPDK devices in DPDK application, right? If implementing all DPDK setup in DPDK, the only thing to do in system config, is to NOT use the device (set IP, etc). So preparing the devices for DPDK (or other userpace app) as part of the system setup is an addition. Note: I don't know which decision is better, I am just trying to think about what the solutions are.