On 1/17/2017 7:00 PM, Ferruh Yigit wrote: > On 1/17/2017 6:44 PM, Jay Rolette wrote: >> >> On Tue, Jan 17, 2017 at 12:01 PM, Ferruh Yigit <ferruh.yi...@intel.com >> <mailto:ferruh.yi...@intel.com>> wrote: >> >> KNI ethtool support (KNI control path) is not commonly used, >> and it tends to break the build with new version of the Linux kernel. >> >> KNI ethtool feature is disabled by default. KNI datapath is not effected >> from this update. >> >> It is possible to enable feature explicitly with config option: >> "CONFIG_RTE_KNI_KMOD_ETHTOOL=y" >> >> Signed-off-by: Ferruh Yigit <ferruh.yi...@intel.com >> <mailto:ferruh.yi...@intel.com>> >> >> >> Is there a test case somewhere to detect when it gets broken or is the >> intent to let it bit-rot unless someone enables that option and >> subsequently discovers it broken? >> >> I know we don't do this for every config option, but given the fact that >> this tends to get broken frequently, it seems riskier. > > Agree this has risk to be forgotten/badly broken, I am sharing same concern. > > But what happening was, even we fix DPDK for latest kernel, after DPDK > released, DPDK compilation sometimes broken with new coming kernels. > Since DPDK already released there is way to fix this, and this sometimes
correction: ... there is _no_ way to fix this ... > hit people who won't use KNI ethtool at all. > > KNI ethtool needs to be taken care by its users. > >> >> Jay >> >> >> --- >> config/common_linuxapp | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/config/common_linuxapp b/config/common_linuxapp >> index d4c4f0c..2483dfa 100644 >> --- a/config/common_linuxapp >> +++ b/config/common_linuxapp >> @@ -38,7 +38,6 @@ CONFIG_RTE_EXEC_ENV_LINUXAPP=y >> CONFIG_RTE_EAL_IGB_UIO=y >> CONFIG_RTE_EAL_VFIO=y >> CONFIG_RTE_KNI_KMOD=y >> -CONFIG_RTE_KNI_KMOD_ETHTOOL=y >> CONFIG_RTE_LIBRTE_KNI=y >> CONFIG_RTE_LIBRTE_VHOST=y >> CONFIG_RTE_LIBRTE_PMD_VHOST=y >> -- >> 2.9.3 >> >> >
