From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8BA73A0C4E; Tue, 12 Oct 2021 20:43:36 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 52AF0410E1; Tue, 12 Oct 2021 20:43:36 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id EB6194003C for ; Tue, 12 Oct 2021 20:43:34 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 5C03E5C01BD; Tue, 12 Oct 2021 14:43:34 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 12 Oct 2021 14:43:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= R+QC9NQ87ihSEnpmh4UgkMOcfdSNysOsvLBI88K7elw=; b=Ztrf9YBC1x5QzZk+ mIp//vnokasQEeR4nIq8fu0Y3HiYn9yhM4Ha0USKCZsYozFBoO/v8zvbpximMrAe dSJodLLnGAhqOvJlFGId6ZNUB7e16w5/yBcyUsgJhvHUfGpCo1CuO+DEbqtcsAVq qnAYQFqSkgUV2OgmiN4ea5g/Z2t32Gbt2RBz2rq/ehzicrE5ZXUZAKy4WWhlxayz wieczxnMFQM9JNSLVInOMrB0JQWZtTFDQgEGIryr+zfXxiPGG8EzZ8BpjY22Y5HH KkoYBqFcRClQmgCy8kpLfflm0DSk2dh8xMAko3MAj38h/ezzdHURQ/xq+4k5s6BB Kgd5zA== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=R+QC9NQ87ihSEnpmh4UgkMOcfdSNysOsvLBI88K7e lw=; b=daDTul7ci4/kEMSO/yRHmF3r6bIKer2ccmnC7Mlsdk8kkCEopdDCR3Z5O Z2O5YrnRuF6pfy0BS3t91lHji6YhWS+LVvpjm2tz89kRBcRdGFcWEmB9+R/V6Oeu beBwwAJZQ5fms5tHG7ooYm0dvZei1HZa7O1vvnkjfnZHErVlwDjvxn9ArsuK4ybl VW5hC7Ms5RNEmFsR+pFEo6Mve0nJCsN0gXfjhhfSY++Aru18ib6wuxPYieX4OWwa QqZRevwSii3sH5PtuddU0vh8hhW/RK9EKhrRjwsSnNMH2Yj1WdaV1bA3KmzC6rQP 6kbchkea2KH2NO+dyLOYKLHOHJLGg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddtkedguddvgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedvkeetveeihfegfedtfeejueekkeekueevgfejuedviedvvdev uefgteevtdefveenucffohhmrghinhepughpughkrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 12 Oct 2021 14:43:32 -0400 (EDT) From: Thomas Monjalon To: "Liu, Changpeng" , "Xia, Chenbo" , "Harris, James R" , "Walker, Benjamin" Cc: David Marchand , "dev@dpdk.org" , Aaron Conole , "Zawadzki, Tomasz" Date: Tue, 12 Oct 2021 20:43:28 +0200 Message-ID: <5522719.EOI0ZVpCj1@thomas> In-Reply-To: References: <20210910022402.26620-1-chenbo.xia@intel.com> <2493119.E4WuaiPJut@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 12/10/2021 18:59, Walker, Benjamin: > > From: dev On Behalf Of Thomas Monjalon > > 12/10/2021 02:35, Harris, James R: > > > =EF=BB=BFOn 10/11/21, 5:55 AM, "Thomas Monjalon" wrote: > > > > > > The meson option enable_driver_sdk is described as "Install heade= rs to build > > drivers." > > > Standard development packages should provide headers to build an > > application. > > > This option is for projects extending DPDK drivers out of the tre= e. > > > The preferred option is to develop drivers inside DPDK. > > > > > > If a project needs the special option enable_driver_sdk, > > > 1/ it is not following the recommended approach, > > > 2/ it has to manage the burden of driver compatibility with DPDK, > > > 3/ it can compile DPDK itself. > > > > > > So I think we neither need to make it a default, nor force distro= s to enable it. > > > Am I missing something? > > > > > > Hi Thomas, > > > > > > This preference to develop PCI drivers inside of DPDK seems to be a v= ery > > recent preference. enable_driver_sdk was just added in DPDK 21.05, and= for > > building out-of-tree ethdev drivers. But DPDK has always enabled buildi= ng out- > > of-tree PCI drivers with its default build configuration - SPDK has rel= ied on these > > APIs since its inception. > >=20 > > Yes DPDK allows out-of-tree drivers, but it has never been recommended. >=20 > For networking drivers, maybe. But certainly years and years ago when SPD= K was started no one recommended putting an nvme driver into DPDK. No one from SPDK project proposed such thing. I asked several times in person why that, and even the DPDK techboard asked for such a merge: https://mails.dpdk.org/archives/dev/2018-December/120706.html The reply: http://inbox.dpdk.org/dev/20181217141030.bhe5pwlqnzb3w3i7@platinum/ Even older question in 2015: http://inbox.dpdk.org/dev/6421280.5XkMhqyP4M@xps13/ > > We have introduced enable_driver_sdk option recently to keep allowing o= ut-of- > > tree drivers. > >=20 > > > We have always viewed DPDK as being a very useful toolkit for building > > userspace drivers (especially storage drivers!) that aren't part of DPD= K itself. We > > hope that continues to be the case. > >=20 > > Yes, there is no plan to stop that, but also no plan to make it easier. >=20 > To be clear, this change actively makes it harder. DPDK has changed the l= ongstanding status quo. Yes it requires a compilation option. > > > All of that being said, SPDK already compiles DPDK itself as the defa= ult > > configuration. We maintain a DPDK fork for patches that have not yet hi= t DPDK > > upstream. If this gets merged we can document that users building DPDK > > themselves must set enable_driver_sdk. We can also document to our user= s that > > SPDK may not build against distro DPDK packages, once distros pick up t= hese > > changes. > >=20 > > Yes I think that's the right thing to do. >=20 > This means that a distro-packaged SPDK cannot exist, because it cannot us= e a distro-packaged DPDK as a dependency. I don't think so. Once SPDK is packaged, what do you need from DPDK? I think you need only .so files for some libs like EAL and PCI, so that's available in the DPDK package, right? > While using a distro-packaged SPDK is not the common case (people just bu= ild it themselves), > my personal view is that we need to be able to support this and this chan= ge from DPDK is unacceptable. I agree you should be able to package SPDK. > > Note: I don't remember the reason to keep your drivers out of DPDK? >=20 > SPDK uses DPDK as a framework for writing user space drivers only - scann= ing the PCI bus, allocating DMA-safe memory, etc. This functionality is hid= den behind an abstraction layer that can be reimplemented by our users to r= emove the DPDK dependency entirely, and real production users have elected = to do this. The reasons they do this are varied, but the shortest way to sa= y it is that DPDK is a framework that requires their application to buy-in = across the board, whereas SPDK is a set of libraries that integrates into t= heir existing application more easily. >=20 > SPDK simply uses DPDK as the default implementation for this functionalit= y. We cannot port our drivers into DPDK or it would break this use case. >=20 > Thanks, > Ben