From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id 499AF2BB1 for ; Thu, 15 Jun 2017 16:48:42 +0200 (CEST) Received: by mail-wm0-f41.google.com with SMTP id n195so1600176wmg.1 for ; Thu, 15 Jun 2017 07:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=msYVTNoJjC0sM9X+y3pSZUFXLSvEbzN2iyGozzgc9fk=; b=Tf0V+VABJ1KfMpomIUdScp/5FSdF6y0hennh0gNIZbFoTE6CUj1yMGa38t97+hHLIF 37DrD/PmCDhWqXdLaxuR3mJO24Clqm4Wqwv8hA77vTkewhdnymPoHaRUEqA3WLu/XQU/ 7UnjLvTYYHPaTI5qNGIrWhp2nrhP+CL3/xPqbcRquLrSQYNJhARdBxTqsfwCAcB9PvEv ieZicXiZrDBVpCGIzcwkNIvyjLKIt1rkgl7d88h+VZMZzJw7MsnS558KGGRve2NX0g7N 9XI+e7m2CFwdP99Pf1dxvh2P+HI1R7OT4eZ1MDfJRoc0hvSup0BtKPRDmG1JjoomywoC iV/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=msYVTNoJjC0sM9X+y3pSZUFXLSvEbzN2iyGozzgc9fk=; b=rkj8ojpyfTW4F1hjvJnq8iycRJ77Ip80NmxwMQ+suOThX40KwxotkFZVRFOShlFnNd MddNEq0lmUaNn9wWkWAChX3z5lKTlUArZ0PuLkp33YoFy6KONjyzeefxIBAzJW4T+zdc FCHfhpAL7H3Md6qOcoK7PFEV7JkqQUbq5UTKpuTBpFkRn/IZpKiFlRNg14AAxMCaUGxG AYEw8nO+qZT/6NB2yyOmf8b7iJkyZen2zRJjd7fyL4/qMuBH74R7ixBVg4JktkdsHZje vsP90O6Cdv5mRpWRRlyVth+RCKTHesXzDyWgoCYIJuS1Gt1SkuI3Lo49+iSInDrM4WpW e2yQ== X-Gm-Message-State: AKS2vOwOYl24dtJPkclVWdHmRskxkYa4aCrvZkca96mrRk0SSKOEj/LQ 9fWbmReRzpSODTaj X-Received: by 10.28.87.132 with SMTP id l126mr3922610wmb.95.1497538121797; Thu, 15 Jun 2017 07:48:41 -0700 (PDT) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id y17sm379148wrb.39.2017.06.15.07.48.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Jun 2017 07:48:41 -0700 (PDT) Date: Thu, 15 Jun 2017 16:48:33 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Ferruh Yigit Cc: "dev@dpdk.org" Message-ID: <20170615144833.GC29091@bidouze.vm.6wind.com> References: <015f5ab0-1936-44f3-a60e-f4ff9f377262@intel.com> <20170609090609.GC29091@bidouze.vm.6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH v2 08/12] kni: disabled by default 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, 15 Jun 2017 14:48:42 -0000 On Thu, Jun 15, 2017 at 02:09:41PM +0100, Ferruh Yigit wrote: > On 6/9/2017 10:06 AM, Gaëtan Rivet wrote: > > Hi Ferruh, > > > > On Fri, Jun 09, 2017 at 09:56:14AM +0100, Ferruh Yigit wrote: > >> On 6/8/2017 12:59 AM, Gaetan Rivet wrote: > >>> Signed-off-by: Gaetan Rivet > >>> --- > >>> config/common_linuxapp | 2 +- > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>> diff --git a/config/common_linuxapp b/config/common_linuxapp > >>> index b3cf41b..cc85cc6 100644 > >>> --- a/config/common_linuxapp > >>> +++ b/config/common_linuxapp > >>> @@ -38,7 +38,7 @@ CONFIG_RTE_EXEC_ENV_LINUXAPP=y > >>> CONFIG_RTE_EAL_IGB_UIO=y > >>> CONFIG_RTE_EAL_VFIO=y > >>> CONFIG_RTE_KNI_KMOD=y > >>> -CONFIG_RTE_LIBRTE_KNI=y > >>> +CONFIG_RTE_LIBRTE_KNI=n > >>> CONFIG_RTE_LIBRTE_PMD_KNI=y > >>> CONFIG_RTE_LIBRTE_VHOST=y > >>> CONFIG_RTE_LIBRTE_PMD_VHOST=y > >>> > >> > >> Hi Gaetan, > >> > >> We shouldn't just disable components that doesn't compile. > >> > > > > Ah, sure :) . This patch is not meant to be integrated as is, but only > > as a convenient way for testers to apply the patchset and verify the > > compilation, as far as KNI is not concerned. > > > > Eventdev and cryptodev fixed this dependency. I was thinking about > > looking into it for KNI and PDUMP but I don't have the time right now, > > and I'm not sure I will have until the end of June. > > Moved from another mail thread > (http://dpdk.org/ml/archives/dev/2017-June/067936.html) > > >> KNI uses / depends pci, I am not sure what to fix here. > >> > >> The problem to enable the KNI is build dependency problem, right? > >> > >> I guess problem will be fixes if we can build in following order: > >> - lib/eal > >> - drivers/bus > >> - lib > >> - drivers > >> > >> This was the case when bus drives compiled within eal. What do you think > >> about this build order? > >> > > > > Yes, that build order would fix the issue. > > However, IMO this is not the proper way to proceed. > > It obscures the architecture, the distinction between DPDK abstractions > > and their implementations. > > > > Looking quickly into this dependency, it seems that the PCI info is only > > used during allocation, and only to register PCI information within > > device infos. They do not seem used afterward at the library level, > > except to print some device description upon device start. > > > > They can be completely removed from KNI (both from the lib and the > > driver), without breaking the compilation. > > This however changes the API of rte_kni_alloc() and the ABI of > > rte_kni_conf. > > PCI info is not only for printing, it is required for ethtool support. > I see. Sorry, I never really looked into it before. > The pci info sent to KNI kernel module, which uses this information to > associate kernel driver to DPDK interface. Basically this is required > for control part support of KNI. > > So I believe we can't just remove this. > Ok, those infos should stay reachable. Do they have to stay at the same place however? > > Ideally KNI interfaces should be able to use any rte_device, not only > > PCI. But if it is forced to use only PCI devices, then pointing to an > > rte_pci_device seems a better way to proceed, as it has all those infos > > readily available. It would allow the PCI device to grow and evolve > > without breaking the KNI lib. > > Ideally this is good idea to make DPDK libraries bus agnostic. > > But for KNI, it is not just lib/librte_kni, it has a kernel module > counterpart and it needs to know the bus information, in this manner KNI > is different. > > Even if we assume it is possible to make KNI independent from bus, this > effort is not very useful because we don't want to continue KNI ethtool > support as it is (by having Linux NIC drivers in kernel module), so > there won't be any other NIC that benefits from update. > > And option can be replace KNI ethtool support with KCP, but we are > struggling to upstream KCP for a while, and this is another story. > > For specific to KNI, we can say, it is a library that is dependent to > specific bus. I believe build system should be able to support some > components depends to specific bus. > Would it be feasible to have the same kind of bus-specific interface that was added for ethdev, cryptodev, eventdev? Having an rte_pci_device pointer within dev_infos for KNI itself, but setting it while at the drivers/net/kni level? The problem is that it breaks KNI API / ABI. But I believe it's possible this way to reach feature parity while leaving the build order alone. There may be a compromise, where for this release the build order is modified only for KNI and fixed in the next, thus respecting the API change rules in place. Before that call could be made though, we should first determine whether KNI is fixable and a proper solution can be reached without impacting the build order in the long term. Once we have this plan, we can decide whether the priority is the KNI API and its users or the DPDK arch integrity. -- Gaëtan Rivet 6WIND