From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 1E1017EB4 for ; Thu, 19 Apr 2018 10:40:50 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2018 01:40:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,468,1517904000"; d="scan'208";a="34536460" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.51]) by orsmga007.jf.intel.com with SMTP; 19 Apr 2018 01:40:46 -0700 Received: by (sSMTP sendmail emulation); Thu, 19 Apr 2018 09:40:44 +0100 Date: Thu, 19 Apr 2018 09:40:44 +0100 From: Bruce Richardson To: Thomas Monjalon Cc: Alejandro Lucero , Flavio Leitner , Stephen Hemminger , dev , "Burakov, Anatoly" , David Marchand , jia.guo@intel.com, matan@mellanox.com, "Ananyev, Konstantin" Message-ID: <20180419084044.GA11624@bricha3-MOBL.ger.corp.intel.com> References: <2407757.yEAnF6RcS7@xps> <20180418185411.GK2549@plex.lan> <1901154.ialemUER5X@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1901154.ialemUER5X@xps> Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.9.4 (2018-02-28) 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:40:51 -0000 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.