On 10/11/21, 5:55 AM, "Thomas Monjalon" <[email protected]> wrote:
11/10/2021 08:58, Xia, Chenbo:
> From: Liu, Changpeng <[email protected]>
> > 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.
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.
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.
-Jim
