New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmake: WITH_SPDK=ON by default #18944
Conversation
@@ -29,6 +29,7 @@ Build-Depends: bc, | |||
libbabeltrace-ctf-dev, | |||
libbabeltrace-dev, | |||
libblkid-dev (>= 2.17), | |||
libcunit1-dev, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@liupan1111 this what i mean by debian/control
.
@@ -183,6 +183,7 @@ BuildRequires: keyutils-libs-devel | |||
BuildRequires: libibverbs-devel | |||
BuildRequires: openldap-devel | |||
BuildRequires: openssl-devel | |||
BuildRequires: CUnit-devel |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@smithfarm does this work for SLE? or do you want to WITH_SPDK=ON for the build also?
cmake/modules/BuildDPDK.cmake
Outdated
set(machine "armv8a") | ||
elseif(CMAKE_SYSTEM_PROCESSOR MATCHES "(powerpc|ppc)64") | ||
set(arch "ppc_64") | ||
set(machine "power8") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@smithfarm do you think we should enable DPDK on "power8" also? as http://dpdk.org/doc/guides/linux_gsg/build_dpdk.html claims that DPDK supports power8 as well.
b13d8a7
to
ab4bf0c
Compare
cmake/modules/BuildDPDK.cmake
Outdated
endif() | ||
|
||
if(WITH_KERNEL_DIR) | ||
if(NOT IS_DIRECTORY ${WITH_KERNEL_DIR}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@liupan1111 this is my biggest concern. the target machine's kernel is not always the same as the build host. even if we managed to fulfill the build-requirement by installing the package of linux-headers-`uname -r`
, there is good chance that the built DPDK kernel module does not work for the deployed machine.
or we don't need to build the kernel module at all? if yes, how?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand the kernel version dependency. Does the build have to be built against a specific kernel? I.e., if we build on the centos 7.3 kernel will the built resuilt break on 7.4? Or a build on the 16.04 kernel break on a later HWE kernel?
As long as those scenerios behave okay, I think it's fine to continue. If there is a hard kernel dependency, then I'm not sure what we should do.. that would suck. :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For SLE, I'm pretty sure kernel module code needs to be integrated into, built as part of, and shipped in the kernel package itself. That may be an oversimplification, but certainly I wouldn't expect to be building kernel module packages via ceph.spec
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ddiss Can you vet my comment, above?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, to my best knowledge, kernel modules are not portable across different versions. anyway, i am disabling the kernel modules in DPDK.
@liupan1111 could you help test the build w/o the kernel modules? thanks
@tchaikov As usual, I'm running behind. . . I haven't tried to build master on SLE lately. I will try building this branch and let you know the result. |
2aa0b61
to
2415725
Compare
cmake/modules/patch-dpdk-conf.sh
Outdated
setconf CONFIG_RTE_KNI_KMOD n | ||
setconf CONFIG_RTE_KNI_PREEMPT_DEFAULT n | ||
|
||
setconf CONFIG_RTE_APP_EVENTDEV n |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i know, this option is not in the used DPDK yet.
machine=$1 | ||
shift | ||
|
||
setconf CONFIG_RTE_MACHINE "${machine}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@yuyuyu101 do you think we can have a functional SPDK backend without all these kernel modules?
2fd5c65
to
88a1081
Compare
97e824d
to
bcc3cb0
Compare
@smithfarm shaman is happy, see https://shaman.ceph.com/builds/ceph/wip-18944-kefu/bcc3cb0ba31d40a500391819ae9933cc84c204f9/. could you give the branch a spin? |
4b11a59
to
42f6fc2
Compare
42f6fc2
to
c1dfc49
Compare
@@ -348,6 +348,10 @@ endif() | |||
|
|||
option(WITH_DPDK "Enable DPDK messaging" OFF) | |||
if(WITH_DPDK) | |||
if(NOT USE_CRYPTOPP) | |||
message(FATAL_ERROR "CRYPTOPP must be supported when enable DPDK.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the the incompatible option settings at the toplevel cmake script.
@@ -687,6 +657,32 @@ if(HAVE_ARMV8_CRC) | |||
list(APPEND ceph_common_deps common_crc_aarch64) | |||
endif(HAVE_ARMV8_CRC) | |||
|
|||
if(WITH_DPDK) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so we can have the WITH_DPDK
support in a single place.
target_link_libraries(common_async_dpdk | ||
${DPDK_LIBRARIES}) | ||
set_target_properties(common_async_dpdk PROPERTIES | ||
COMPILE_FLAGS "-march=native -I${DPDK_INCLUDE_DIR}") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so we can avoid adding "-march=native" globally. this will be a show stopper for downstream packagers/maintainers, if we want to enable DPDK by default.
Signed-off-by: Kefu Chai <kchai@redhat.com> Signed-off-by: wanjun.lp <wanjun.lp@alibaba-inc.com> Signed-off-by: Ziye Yang <optimistyzy@gmail.com>
c1dfc49
to
34bb7d3
Compare
Signed-off-by: Kefu Chai <kchai@redhat.com>
Signed-off-by: wanjun.lp <wanjun.lp@alibaba-inc.com> Signed-off-by: Kefu Chai <kchai@redhat.com>
34bb7d3
to
0e5e3af
Compare
@tchaikov does your PR support the following 3 cases:
|
@tchaikov Maybe you need squash the several commits into one before merge it. |
* move the check of `USE_CRYPTOPP` to $top_srcdir/CMakeLists.txt * remove reference of DPDK_LIBRARY, it's defined nowhere * move the dpdk code to a single place Signed-off-by: Kefu Chai <kchai@redhat.com>
Signed-off-by: Kefu Chai <kchai@redhat.com>
see also http://pkgs.fedoraproject.org/cgit/rpms/dpdk.git/tree/dpdk.spec Signed-off-by: Kefu Chai <kchai@redhat.com>
* also refactor it a little bit Signed-off-by: Kefu Chai <kchai@redhat.com>
Signed-off-by: Kefu Chai <kchai@redhat.com>
Signed-off-by: Liu-Chunmei <chunmei.liu@intel.com>
0e5e3af
to
0610332
Compare
@liu-chunmei i squashed the two DPDK cleanup changes into a single one. but i'd like to keep other changes separated commits. as in this way, smaller changes will help the posterity to understand changes. and all combinations of |
No description provided.