From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: kernel binding of devices + hotplug Date: Thu, 19 Apr 2018 10:24:24 +0200 Message-ID: <1901154.ialemUER5X@xps> References: <2407757.yEAnF6RcS7@xps> <20180418185411.GK2549@plex.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: Flavio Leitner , Stephen Hemminger , dev , Bruce Richardson , "Burakov, Anatoly" , David Marchand , jia.guo@intel.com, matan@mellanox.com, "Ananyev, Konstantin" To: Alejandro Lucero 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) In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 > > >