12/10/2021 02:35, Harris, James R: > On 10/11/21, 5:55 AM, "Thomas Monjalon" <tho...@monjalon.net> wrote: > > 11/10/2021 08:58, Xia, Chenbo: > > From: Liu, Changpeng <changpeng....@intel.com> > > > Another issue raised by Jim Harris is that for distro packaged DPDK, > since > > > this option isn't enabled by default, this will not allow SPDK > > > to use the distro packaged DPDK after this release. > > > > I think for this problem, we have two options: enable driver sdk by > default or > > let OSV configure the option when building distros. I'm fine with > either option. > > 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. 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. > 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. Note: I don't remember the reason to keep your drivers out of DPDK?
