DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "Liu, Changpeng" <changpeng.liu@intel.com>,
	"Xia, Chenbo" <chenbo.xia@intel.com>,
	"Harris, James R" <james.r.harris@intel.com>,
	"Walker, Benjamin" <benjamin.walker@intel.com>
Cc: David Marchand <david.marchand@redhat.com>,
	"dev@dpdk.org" <dev@dpdk.org>, Aaron Conole <aconole@redhat.com>,
	"Zawadzki, Tomasz" <tomasz.zawadzki@intel.com>
Subject: Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
Date: Tue, 12 Oct 2021 20:43:28 +0200	[thread overview]
Message-ID: <5522719.EOI0ZVpCj1@thomas> (raw)
In-Reply-To: <BYAPR11MB28247DF0DEF28293481681D4EFB69@BYAPR11MB2824.namprd11.prod.outlook.com>

12/10/2021 18:59, Walker, Benjamin:
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Thomas Monjalon
> > 12/10/2021 02:35, Harris, James R:
> > > On 10/11/21, 5:55 AM, "Thomas Monjalon" <thomas@monjalon.net> wrote:
> > >
> > >     The meson option enable_driver_sdk is described as "Install headers to build
> > drivers."
> > >     Standard development packages should provide headers to build an
> > application.
> > >     This option is for projects extending DPDK drivers out of the tree.
> > >     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 distros to enable it.
> > >     Am I missing something?
> > >
> > > Hi Thomas,
> > >
> > > This preference to develop PCI drivers inside of DPDK seems to be a very
> > 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 building out-
> > of-tree PCI drivers with its default build configuration - SPDK has relied on these
> > APIs since its inception.
> > 
> > Yes DPDK allows out-of-tree drivers, but it has never been recommended.
> 
> For networking drivers, maybe. But certainly years and years ago when SPDK 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 out-of-
> > tree drivers.
> > 
> > > We have always viewed DPDK as being a very useful toolkit for building
> > userspace drivers (especially storage drivers!) that aren't part of DPDK itself.  We
> > hope that continues to be the case.
> > 
> > Yes, there is no plan to stop that, but also no plan to make it easier.
> 
> To be clear, this change actively makes it harder. DPDK has changed the longstanding status quo.

Yes it requires a compilation option.


> > > All of that being said, SPDK already compiles DPDK itself as the default
> > configuration. We maintain a DPDK fork for patches that have not yet hit 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 users that
> > SPDK may not build against distro DPDK packages, once distros pick up these
> > changes.
> > 
> > Yes I think that's the right thing to do.
> 
> This means that a distro-packaged SPDK cannot exist, because it cannot use 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 build it themselves),
> my personal view is that we need to be able to support this and this change 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?
> 
> SPDK uses DPDK as a framework for writing user space drivers only - scanning the PCI bus, allocating DMA-safe memory, etc. This functionality is hidden behind an abstraction layer that can be reimplemented by our users to remove 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 say 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 their existing application more easily.
> 
> SPDK simply uses DPDK as the default implementation for this functionality. We cannot port our drivers into DPDK or it would break this use case.
> 
> Thanks,
> Ben



  reply	other threads:[~2021-10-12 18:43 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-10  2:23 [dpdk-dev] [PATCH 0/8] " Chenbo Xia
2021-09-10  2:23 ` [dpdk-dev] [PATCH 1/8] bus/pci: add new memory resource access APIs Chenbo Xia
2021-09-13 11:59   ` Kinsella, Ray
2021-09-10  2:23 ` [dpdk-dev] [PATCH 2/8] app/testpmd: use PCI " Chenbo Xia
2021-09-16  6:10   ` Li, Xiaoyun
2021-09-16  6:38     ` Xia, Chenbo
2021-09-10  2:23 ` [dpdk-dev] [PATCH 3/8] examples/ethtool: use PCI library API to get PCI address Chenbo Xia
2021-09-10  2:23 ` [dpdk-dev] [PATCH 4/8] examples/kni: remove unused PCI bus header Chenbo Xia
2021-09-17 15:38   ` Ferruh Yigit
2021-09-10  2:23 ` [dpdk-dev] [PATCH 5/8] test/kni: remove setting of PCI ID and address Chenbo Xia
2021-09-10  7:12   ` David Marchand
2021-09-17 15:38   ` Ferruh Yigit
2021-09-10  2:24 ` [dpdk-dev] [PATCH 6/8] examples/ip_pipeline: " Chenbo Xia
2021-09-10  7:18   ` David Marchand
2021-09-10  8:21     ` Xia, Chenbo
2021-09-17  3:09     ` Xia, Chenbo
2021-09-17 11:55       ` David Marchand
2021-09-17 15:37         ` Ferruh Yigit
2021-09-10  2:24 ` [dpdk-dev] [PATCH 7/8] kni: replace unused variable definition with reserved bytes Chenbo Xia
2021-09-10  2:24 ` [dpdk-dev] [PATCH 8/8] bus/pci: remove ABIs in PCI bus Chenbo Xia
2021-09-13 12:06   ` Kinsella, Ray
2021-09-14  8:15   ` Xu, Rosen
2021-09-18  2:24 ` [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs Chenbo Xia
2021-09-18  2:24   ` [dpdk-dev] [PATCH v2 1/7] bus/pci: add new memory resource access APIs Chenbo Xia
2021-09-18  2:24   ` [dpdk-dev] [PATCH v2 2/7] app/testpmd: use PCI " Chenbo Xia
2021-09-18  2:44     ` Li, Xiaoyun
2021-09-18  2:24   ` [dpdk-dev] [PATCH v2 3/7] examples/ethtool: use PCI library API to get PCI address Chenbo Xia
2021-09-18  2:24   ` [dpdk-dev] [PATCH v2 4/7] examples/kni: remove unused PCI bus header Chenbo Xia
2021-09-18  2:24   ` [dpdk-dev] [PATCH v2 5/7] kni: remove unused PCI info from test and example Chenbo Xia
2021-09-18  2:24   ` [dpdk-dev] [PATCH v2 6/7] kni: replace unused variable definition with reserved bytes Chenbo Xia
2021-09-18  2:24   ` [dpdk-dev] [PATCH v2 7/7] bus/pci: remove ABIs in PCI bus Chenbo Xia
2021-09-29  7:38   ` [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs Xia, Chenbo
2021-09-30  8:45     ` David Marchand
2021-10-04 13:37       ` David Marchand
2021-10-04 15:56         ` Harris, James R
2021-10-06  4:25           ` Xia, Chenbo
2021-10-08  6:15             ` Liu, Changpeng
2021-10-08  7:08               ` David Marchand
2021-10-08  7:44                 ` Liu, Changpeng
2021-10-11  6:58                   ` Xia, Chenbo
2021-10-11 12:55                     ` Thomas Monjalon
2021-10-12  0:35                       ` Harris, James R
2021-10-12  7:04                         ` Thomas Monjalon
2021-10-12 16:59                           ` Walker, Benjamin
2021-10-12 18:43                             ` Thomas Monjalon [this message]
2021-10-12 19:26                               ` Walker, Benjamin
2021-10-12 21:50                                 ` Thomas Monjalon
2021-10-13 17:56                                   ` Walker, Benjamin
2021-10-13 18:59                                     ` Thomas Monjalon
2021-10-13 22:48                                       ` Walker, Benjamin
2021-10-14  6:41                                         ` Thomas Monjalon
2022-07-11 12:11                                           ` Thomas Monjalon
2021-10-14  2:21                                       ` Xia, Chenbo
2021-10-14  6:41                                         ` Thomas Monjalon
2021-10-14  7:00                                           ` Xia, Chenbo
2021-10-14  7:07                                             ` Thomas Monjalon
2021-10-14  8:07                                               ` Xia, Chenbo
2021-10-14  8:25                                                 ` Thomas Monjalon
2021-10-27 12:03                                                   ` Xia, Chenbo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5522719.EOI0ZVpCj1@thomas \
    --to=thomas@monjalon.net \
    --cc=aconole@redhat.com \
    --cc=benjamin.walker@intel.com \
    --cc=changpeng.liu@intel.com \
    --cc=chenbo.xia@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=james.r.harris@intel.com \
    --cc=tomasz.zawadzki@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).