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 AB79C2A62 for ; Thu, 19 Apr 2018 10:24:28 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 261AE21B5B; Thu, 19 Apr 2018 04:24:27 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 19 Apr 2018 04:24:27 -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=sOu/mq8lbejxI+gfDRiLLfEmZt zZrgr91oumrwvwKv0=; b=oDsBtOA5zu3rulspTWIcuqLghgB2pi9sM9oNMoE76H 5twouZMrT3nh/ea7kMMp2x5nmOl2aouR1jyG78J4Jx2PwGeszaFT3zEQZcHqL4DL DXvUdHAvoins9+vci1PlNfLjkHoy/TIMjICiBP6S0bdJuwxvPcMApR+hBxpD7Ss+ 4= 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=sOu/mq 8lbejxI+gfDRiLLfEmZtzZrgr91oumrwvwKv0=; b=joZWLSP7enJIWDvX+cdHS5 nn6+1r9I6R/JHHwf8cpxQfcfaN6f+tqbpnB5cERodn5BoL5cTptCdkvlVWpnuVXF 4UA3n+wFe09IfA0tcOenDySXkK2KtzqzP34nygws9RiDaH2a5FrKD4ZMH9PSPUFk ySk9/ASjqgC4nlzua4kM0+XkJQZkbi2OLtMj3roQMmWYa6ORSpNKVMuQWByEWA1U GGZtv4inLpyT9mJP63sc26eBqOBoGcUcPaBlisQ71GIcVtqSEHYeFpzundSClSGT yfTcRrmAPfF7CxINvmEmJum3qO089+hO6myPyjX8zquEDsSNY9C6TQD4QsNxL3GQ == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id CCCD3E4437; Thu, 19 Apr 2018 04:24:25 -0400 (EDT) From: Thomas Monjalon To: Alejandro Lucero Cc: Flavio Leitner , Stephen Hemminger , dev , Bruce Richardson , "Burakov, Anatoly" , David Marchand , jia.guo@intel.com, matan@mellanox.com, "Ananyev, Konstantin" Date: Thu, 19 Apr 2018 10:24:24 +0200 Message-ID: <1901154.ialemUER5X@xps> In-Reply-To: References: <2407757.yEAnF6RcS7@xps> <20180418185411.GK2549@plex.lan> 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 08:24:29 -0000 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. > On Wed, Apr 18, 2018 at 7:54 PM, Flavio Leitner wrote: > > On Wed, Apr 18, 2018 at 11:17:47AM -0700, Stephen Hemminger wrote: > > > On Wed, 18 Apr 2018 11:11:01 -0300 > > > Flavio Leitner wrote: > > > > On Sun, Apr 15, 2018 at 01:48:36AM +0000, Stephen Hemminger wrote: > > > > > My vote is to work with udev and not try to replace it. > > > > > > > > > > Driverctl works well. Just not for bifurcated driver > > > > > > > > I second that. We also have other system configs to care about like > > > > kernel parameters and hugepage configuration which I think follow the > > > > same idea that they are system wide configs and should not be managed > > > > by DPDK itself. > > > > > > Maybe teach driverctl (and udev) to handle bifurcated drivers. > > > > I don't know the challenges to tech driverctl to handle bifurcated > > drivers but I would agree that it should be our first place to look at. > > > > > Unfortunately, vendors are very fractured on how network devices are > > managed. > > > > You mean distros? hw vendors? all vendors? :) > > > > Perhaps if community focus on something, then they might follow at some > > point. > > > > -- > > Flavio > > >