DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [PATCH] mk: fix kernel modules build dependency
@ 2018-03-29 15:39 Thomas Monjalon
  2018-03-29 15:48 ` Ferruh Yigit
  0 siblings, 1 reply; 14+ messages in thread
From: Thomas Monjalon @ 2018-03-29 15:39 UTC (permalink / raw)
  To: hemant.agrawal; +Cc: dev

Some kernel modules may need some header files to be "installed"
in the build directory.

When running multiple threads of make, kernel modules can try to
be compiled before the lib headers are ready:
	make -j3
	kernel/linux/kni/kni_misc.c:19:37: fatal error:
		exec-env/rte_kni_common.h: No such file or directory

This error appeared recently after moving kernel modules in their
own directory.

Fixes: acaa9ee991b5 ("move kernel modules directories")

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>

---

On a related note, this header file
	lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
could be moved to lib/librte_kni/
Opinion?
---
 mk/rte.sdkbuild.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
index 53e0721e9..5dc43e429 100644
--- a/mk/rte.sdkbuild.mk
+++ b/mk/rte.sdkbuild.mk
@@ -14,6 +14,7 @@ endif
 -include $(RTE_SDK)/mk/exec-env/$(RTE_EXEC_ENV)/rte.custom.mk
 
 buildtools: | lib
+kernel: | lib
 drivers: | lib buildtools
 app: | lib buildtools drivers
 test: | lib buildtools drivers
-- 
2.16.2

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-dev] [PATCH] mk: fix kernel modules build dependency
  2018-03-29 15:39 [dpdk-dev] [PATCH] mk: fix kernel modules build dependency Thomas Monjalon
@ 2018-03-29 15:48 ` Ferruh Yigit
  2018-03-29 16:32   ` Thomas Monjalon
  0 siblings, 1 reply; 14+ messages in thread
From: Ferruh Yigit @ 2018-03-29 15:48 UTC (permalink / raw)
  To: Thomas Monjalon, hemant.agrawal; +Cc: dev

On 3/29/2018 4:39 PM, Thomas Monjalon wrote:
> Some kernel modules may need some header files to be "installed"
> in the build directory.
> 
> When running multiple threads of make, kernel modules can try to
> be compiled before the lib headers are ready:
> 	make -j3
> 	kernel/linux/kni/kni_misc.c:19:37: fatal error:
> 		exec-env/rte_kni_common.h: No such file or directory

Is there a reason to keep header in eal when module itself moved into kernel?

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-dev] [PATCH] mk: fix kernel modules build dependency
  2018-03-29 15:48 ` Ferruh Yigit
@ 2018-03-29 16:32   ` Thomas Monjalon
  2018-03-29 16:38     ` Ferruh Yigit
  0 siblings, 1 reply; 14+ messages in thread
From: Thomas Monjalon @ 2018-03-29 16:32 UTC (permalink / raw)
  To: Ferruh Yigit; +Cc: hemant.agrawal, dev

29/03/2018 17:48, Ferruh Yigit:
> On 3/29/2018 4:39 PM, Thomas Monjalon wrote:
> > Some kernel modules may need some header files to be "installed"
> > in the build directory.
> > 
> > When running multiple threads of make, kernel modules can try to
> > be compiled before the lib headers are ready:
> > 	make -j3
> > 	kernel/linux/kni/kni_misc.c:19:37: fatal error:
> > 		exec-env/rte_kni_common.h: No such file or directory
> 
> Is there a reason to keep header in eal when module itself moved into kernel?

It seems you missed my comment below:

On a related note, this header file
        lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
could be moved to lib/librte_kni/
Opinion?

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-dev] [PATCH] mk: fix kernel modules build dependency
  2018-03-29 16:32   ` Thomas Monjalon
@ 2018-03-29 16:38     ` Ferruh Yigit
  2018-03-29 16:43       ` Thomas Monjalon
  0 siblings, 1 reply; 14+ messages in thread
From: Ferruh Yigit @ 2018-03-29 16:38 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: hemant.agrawal, dev

On 3/29/2018 5:32 PM, Thomas Monjalon wrote:
> 29/03/2018 17:48, Ferruh Yigit:
>> On 3/29/2018 4:39 PM, Thomas Monjalon wrote:
>>> Some kernel modules may need some header files to be "installed"
>>> in the build directory.
>>>
>>> When running multiple threads of make, kernel modules can try to
>>> be compiled before the lib headers are ready:
>>> 	make -j3
>>> 	kernel/linux/kni/kni_misc.c:19:37: fatal error:
>>> 		exec-env/rte_kni_common.h: No such file or directory
>>
>> Is there a reason to keep header in eal when module itself moved into kernel?
> 
> It seems you missed my comment below:
> 
> On a related note, this header file
>         lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
> could be moved to lib/librte_kni/
> Opinion?

Ahh, yes we are saying same thing.
But not sure if it should go under lib/librte_kni/ or kernel/linux/kni/?
I lean to kernel/linux/kni/.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-dev] [PATCH] mk: fix kernel modules build dependency
  2018-03-29 16:38     ` Ferruh Yigit
@ 2018-03-29 16:43       ` Thomas Monjalon
  2018-03-29 16:50         ` Ferruh Yigit
  0 siblings, 1 reply; 14+ messages in thread
From: Thomas Monjalon @ 2018-03-29 16:43 UTC (permalink / raw)
  To: Ferruh Yigit; +Cc: hemant.agrawal, dev

29/03/2018 18:38, Ferruh Yigit:
> On 3/29/2018 5:32 PM, Thomas Monjalon wrote:
> > 29/03/2018 17:48, Ferruh Yigit:
> >> On 3/29/2018 4:39 PM, Thomas Monjalon wrote:
> >>> Some kernel modules may need some header files to be "installed"
> >>> in the build directory.
> >>>
> >>> When running multiple threads of make, kernel modules can try to
> >>> be compiled before the lib headers are ready:
> >>> 	make -j3
> >>> 	kernel/linux/kni/kni_misc.c:19:37: fatal error:
> >>> 		exec-env/rte_kni_common.h: No such file or directory
> >>
> >> Is there a reason to keep header in eal when module itself moved into kernel?
> > 
> > It seems you missed my comment below:
> > 
> > On a related note, this header file
> >         lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
> > could be moved to lib/librte_kni/
> > Opinion?
> 
> Ahh, yes we are saying same thing.
> But not sure if it should go under lib/librte_kni/ or kernel/linux/kni/?
> I lean to kernel/linux/kni/.

Why in kernel/?

Logically, kernel/ depends on lib/ but not the reverse.

And regarding the licensing, we avoid BSD files in Linux modules.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-dev] [PATCH] mk: fix kernel modules build dependency
  2018-03-29 16:43       ` Thomas Monjalon
@ 2018-03-29 16:50         ` Ferruh Yigit
  2018-03-29 17:01           ` Thomas Monjalon
  0 siblings, 1 reply; 14+ messages in thread
From: Ferruh Yigit @ 2018-03-29 16:50 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: hemant.agrawal, dev

On 3/29/2018 5:43 PM, Thomas Monjalon wrote:
> 29/03/2018 18:38, Ferruh Yigit:
>> On 3/29/2018 5:32 PM, Thomas Monjalon wrote:
>>> 29/03/2018 17:48, Ferruh Yigit:
>>>> On 3/29/2018 4:39 PM, Thomas Monjalon wrote:
>>>>> Some kernel modules may need some header files to be "installed"
>>>>> in the build directory.
>>>>>
>>>>> When running multiple threads of make, kernel modules can try to
>>>>> be compiled before the lib headers are ready:
>>>>> 	make -j3
>>>>> 	kernel/linux/kni/kni_misc.c:19:37: fatal error:
>>>>> 		exec-env/rte_kni_common.h: No such file or directory
>>>>
>>>> Is there a reason to keep header in eal when module itself moved into kernel?
>>>
>>> It seems you missed my comment below:
>>>
>>> On a related note, this header file
>>>         lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
>>> could be moved to lib/librte_kni/
>>> Opinion?
>>
>> Ahh, yes we are saying same thing.
>> But not sure if it should go under lib/librte_kni/ or kernel/linux/kni/?
>> I lean to kernel/linux/kni/.
> 
> Why in kernel/?
> 
> Logically, kernel/ depends on lib/ but not the reverse.
> 
> And regarding the licensing, we avoid BSD files in Linux modules.

>From functionality point of view, module provides the functionality and it
should provide the header, this can be all subjective tough :)

Or in other words, if you have the kernel module, you can write another piece of
userspace application (without using librte_kni) and it will be functional.
But if you have the librte_kni only, it won't be functional on its own.

Providing header with kernel enables other userspace app to user KNI.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-dev] [PATCH] mk: fix kernel modules build dependency
  2018-03-29 16:50         ` Ferruh Yigit
@ 2018-03-29 17:01           ` Thomas Monjalon
  2018-03-29 18:12             ` Hemant Agrawal
  2018-03-29 18:21             ` Ferruh Yigit
  0 siblings, 2 replies; 14+ messages in thread
From: Thomas Monjalon @ 2018-03-29 17:01 UTC (permalink / raw)
  To: Ferruh Yigit; +Cc: hemant.agrawal, dev

29/03/2018 18:50, Ferruh Yigit:
> On 3/29/2018 5:43 PM, Thomas Monjalon wrote:
> > 29/03/2018 18:38, Ferruh Yigit:
> >> On 3/29/2018 5:32 PM, Thomas Monjalon wrote:
> >>> 29/03/2018 17:48, Ferruh Yigit:
> >>>> On 3/29/2018 4:39 PM, Thomas Monjalon wrote:
> >>>>> Some kernel modules may need some header files to be "installed"
> >>>>> in the build directory.
> >>>>>
> >>>>> When running multiple threads of make, kernel modules can try to
> >>>>> be compiled before the lib headers are ready:
> >>>>> 	make -j3
> >>>>> 	kernel/linux/kni/kni_misc.c:19:37: fatal error:
> >>>>> 		exec-env/rte_kni_common.h: No such file or directory
> >>>>
> >>>> Is there a reason to keep header in eal when module itself moved into kernel?
> >>>
> >>> It seems you missed my comment below:
> >>>
> >>> On a related note, this header file
> >>>         lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
> >>> could be moved to lib/librte_kni/
> >>> Opinion?
> >>
> >> Ahh, yes we are saying same thing.
> >> But not sure if it should go under lib/librte_kni/ or kernel/linux/kni/?
> >> I lean to kernel/linux/kni/.
> > 
> > Why in kernel/?
> > 
> > Logically, kernel/ depends on lib/ but not the reverse.
> > 
> > And regarding the licensing, we avoid BSD files in Linux modules.
> 
> From functionality point of view, module provides the functionality and it
> should provide the header, this can be all subjective tough :)
> 
> Or in other words, if you have the kernel module, you can write another piece of
> userspace application (without using librte_kni) and it will be functional.
> But if you have the librte_kni only, it won't be functional on its own.
> 
> Providing header with kernel enables other userspace app to user KNI.

So you are saying we should reverse the dependency?
It would mean moving all headers used by kernel modules in kernel/ directory:
	- rte_pci_dev_features.h
	\- rte_pci_dev_feature_defs.h
	- rte_kni_common.h
	\- rte_common.h

Are you sure?

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-dev] [PATCH] mk: fix kernel modules build dependency
  2018-03-29 17:01           ` Thomas Monjalon
@ 2018-03-29 18:12             ` Hemant Agrawal
  2018-03-29 18:28               ` Ferruh Yigit
  2018-03-29 18:21             ` Ferruh Yigit
  1 sibling, 1 reply; 14+ messages in thread
From: Hemant Agrawal @ 2018-03-29 18:12 UTC (permalink / raw)
  To: Thomas Monjalon, Ferruh Yigit; +Cc: dev

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Thursday, March 29, 2018 10:31 PM
> To: Ferruh Yigit <ferruh.yigit@intel.com>
> Cc: Hemant Agrawal <hemant.agrawal@nxp.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] mk: fix kernel modules build dependency
> Importance: High
> 
> 29/03/2018 18:50, Ferruh Yigit:
> > On 3/29/2018 5:43 PM, Thomas Monjalon wrote:
> > > 29/03/2018 18:38, Ferruh Yigit:
> > >> On 3/29/2018 5:32 PM, Thomas Monjalon wrote:
> > >>> 29/03/2018 17:48, Ferruh Yigit:
> > >>>> On 3/29/2018 4:39 PM, Thomas Monjalon wrote:
> > >>>>> Some kernel modules may need some header files to be "installed"
> > >>>>> in the build directory.
> > >>>>>
> > >>>>> When running multiple threads of make, kernel modules can try to
> > >>>>> be compiled before the lib headers are ready:
> > >>>>> 	make -j3
> > >>>>> 	kernel/linux/kni/kni_misc.c:19:37: fatal error:
> > >>>>> 		exec-env/rte_kni_common.h: No such file or directory
> > >>>>
> > >>>> Is there a reason to keep header in eal when module itself moved into
> kernel?
> > >>>
> > >>> It seems you missed my comment below:
> > >>>
> > >>> On a related note, this header file
> > >>>
> > >>> lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
> > >>> could be moved to lib/librte_kni/
> > >>> Opinion?
> > >>
> > >> Ahh, yes we are saying same thing.
> > >> But not sure if it should go under lib/librte_kni/ or kernel/linux/kni/?
> > >> I lean to kernel/linux/kni/.
> > >
> > > Why in kernel/?
> > >
> > > Logically, kernel/ depends on lib/ but not the reverse.
> > >
> > > And regarding the licensing, we avoid BSD files in Linux modules.
> >
> > From functionality point of view, module provides the functionality
> > and it should provide the header, this can be all subjective tough :)
> >
> > Or in other words, if you have the kernel module, you can write
> > another piece of userspace application (without using librte_kni) and it will be
> functional.
> > But if you have the librte_kni only, it won't be functional on its own.
> >
> > Providing header with kernel enables other userspace app to user KNI.
> 
> So you are saying we should reverse the dependency?
> It would mean moving all headers used by kernel modules in kernel/ directory:
> 	- rte_pci_dev_features.h
> 	\- rte_pci_dev_feature_defs.h
> 	- rte_kni_common.h
> 	\- rte_common.h
> 
> Are you sure?
> 
I agree that ideologically the kernel modules shall be self sufficient.
However, given the dpdk structure, my original intention was to have userspace self sufficient. The kernel modules may depend on userspace.

However,  no strong opinion either way.  

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-dev] [PATCH] mk: fix kernel modules build dependency
  2018-03-29 17:01           ` Thomas Monjalon
  2018-03-29 18:12             ` Hemant Agrawal
@ 2018-03-29 18:21             ` Ferruh Yigit
  2018-03-29 18:43               ` Ferruh Yigit
  1 sibling, 1 reply; 14+ messages in thread
From: Ferruh Yigit @ 2018-03-29 18:21 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: hemant.agrawal, dev

On 3/29/2018 6:01 PM, Thomas Monjalon wrote:
> 29/03/2018 18:50, Ferruh Yigit:
>> On 3/29/2018 5:43 PM, Thomas Monjalon wrote:
>>> 29/03/2018 18:38, Ferruh Yigit:
>>>> On 3/29/2018 5:32 PM, Thomas Monjalon wrote:
>>>>> 29/03/2018 17:48, Ferruh Yigit:
>>>>>> On 3/29/2018 4:39 PM, Thomas Monjalon wrote:
>>>>>>> Some kernel modules may need some header files to be "installed"
>>>>>>> in the build directory.
>>>>>>>
>>>>>>> When running multiple threads of make, kernel modules can try to
>>>>>>> be compiled before the lib headers are ready:
>>>>>>> 	make -j3
>>>>>>> 	kernel/linux/kni/kni_misc.c:19:37: fatal error:
>>>>>>> 		exec-env/rte_kni_common.h: No such file or directory
>>>>>>
>>>>>> Is there a reason to keep header in eal when module itself moved into kernel?
>>>>>
>>>>> It seems you missed my comment below:
>>>>>
>>>>> On a related note, this header file
>>>>>         lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
>>>>> could be moved to lib/librte_kni/
>>>>> Opinion?
>>>>
>>>> Ahh, yes we are saying same thing.
>>>> But not sure if it should go under lib/librte_kni/ or kernel/linux/kni/?
>>>> I lean to kernel/linux/kni/.
>>>
>>> Why in kernel/?
>>>
>>> Logically, kernel/ depends on lib/ but not the reverse.
>>>
>>> And regarding the licensing, we avoid BSD files in Linux modules.
>>
>> From functionality point of view, module provides the functionality and it
>> should provide the header, this can be all subjective tough :)
>>
>> Or in other words, if you have the kernel module, you can write another piece of
>> userspace application (without using librte_kni) and it will be functional.
>> But if you have the librte_kni only, it won't be functional on its own.
>>
>> Providing header with kernel enables other userspace app to user KNI.
> 
> So you are saying we should reverse the dependency?
> It would mean moving all headers used by kernel modules in kernel/ directory:

No, not talking about moving headers to kernel/ folder. But we can "liberate" J
the kernel modules.

For KNI, rte_kni_common.h is shared between kernel and userspace, can't escape
from it. But why this common header needs to depend other dpdk headers at all?
Indeed commenting out rte_common and rte_config worked fine, it seem there is
already no dependency.

Same thing for igb_uio, why in needs to depend other dpdk headers?
Following seems fixing the issue, yes it is duplication but I think that is OK:
 -#include <rte_pci_dev_features.h>
 +/*#include <rte_pci_dev_features.h>*/
 +enum rte_intr_mode {
 +       RTE_INTR_MODE_NONE = 0,
 +       RTE_INTR_MODE_LEGACY,
 +       RTE_INTR_MODE_MSI,
 +       RTE_INTR_MODE_MSIX
 +};
 +#define RTE_INTR_MODE_NONE_NAME "none"
 +#define RTE_INTR_MODE_LEGACY_NAME "legacy"
 +#define RTE_INTR_MODE_MSI_NAME "msi"
 +#define RTE_INTR_MODE_MSIX_NAME "msix"

> 	- rte_pci_dev_features.h
> 	\- rte_pci_dev_feature_defs.h
> 	- rte_kni_common.h
> 	\- rte_common.h
> 
> Are you sure?
> 
> 

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-dev] [PATCH] mk: fix kernel modules build dependency
  2018-03-29 18:12             ` Hemant Agrawal
@ 2018-03-29 18:28               ` Ferruh Yigit
  0 siblings, 0 replies; 14+ messages in thread
From: Ferruh Yigit @ 2018-03-29 18:28 UTC (permalink / raw)
  To: Hemant Agrawal, Thomas Monjalon; +Cc: dev

On 3/29/2018 7:12 PM, Hemant Agrawal wrote:
>> -----Original Message-----
>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>> Sent: Thursday, March 29, 2018 10:31 PM
>> To: Ferruh Yigit <ferruh.yigit@intel.com>
>> Cc: Hemant Agrawal <hemant.agrawal@nxp.com>; dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH] mk: fix kernel modules build dependency
>> Importance: High
>>
>> 29/03/2018 18:50, Ferruh Yigit:
>>> On 3/29/2018 5:43 PM, Thomas Monjalon wrote:
>>>> 29/03/2018 18:38, Ferruh Yigit:
>>>>> On 3/29/2018 5:32 PM, Thomas Monjalon wrote:
>>>>>> 29/03/2018 17:48, Ferruh Yigit:
>>>>>>> On 3/29/2018 4:39 PM, Thomas Monjalon wrote:
>>>>>>>> Some kernel modules may need some header files to be "installed"
>>>>>>>> in the build directory.
>>>>>>>>
>>>>>>>> When running multiple threads of make, kernel modules can try to
>>>>>>>> be compiled before the lib headers are ready:
>>>>>>>> 	make -j3
>>>>>>>> 	kernel/linux/kni/kni_misc.c:19:37: fatal error:
>>>>>>>> 		exec-env/rte_kni_common.h: No such file or directory
>>>>>>>
>>>>>>> Is there a reason to keep header in eal when module itself moved into
>> kernel?
>>>>>>
>>>>>> It seems you missed my comment below:
>>>>>>
>>>>>> On a related note, this header file
>>>>>>
>>>>>> lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
>>>>>> could be moved to lib/librte_kni/
>>>>>> Opinion?
>>>>>
>>>>> Ahh, yes we are saying same thing.
>>>>> But not sure if it should go under lib/librte_kni/ or kernel/linux/kni/?
>>>>> I lean to kernel/linux/kni/.
>>>>
>>>> Why in kernel/?
>>>>
>>>> Logically, kernel/ depends on lib/ but not the reverse.
>>>>
>>>> And regarding the licensing, we avoid BSD files in Linux modules.
>>>
>>> From functionality point of view, module provides the functionality
>>> and it should provide the header, this can be all subjective tough :)
>>>
>>> Or in other words, if you have the kernel module, you can write
>>> another piece of userspace application (without using librte_kni) and it will be
>> functional.
>>> But if you have the librte_kni only, it won't be functional on its own.
>>>
>>> Providing header with kernel enables other userspace app to user KNI.
>>
>> So you are saying we should reverse the dependency?
>> It would mean moving all headers used by kernel modules in kernel/ directory:
>> 	- rte_pci_dev_features.h
>> 	\- rte_pci_dev_feature_defs.h
>> 	- rte_kni_common.h
>> 	\- rte_common.h
>>
>> Are you sure?
>>
> I agree that ideologically the kernel modules shall be self sufficient.
> However, given the dpdk structure, my original intention was to have userspace self sufficient. The kernel modules may depend on userspace.

Overall agree to make userspace self sufficient, it makes builds more stable.

Specific to librte_kni, it is kind wrapper to kni module, so functionally it is
OK to make librte_kni dependent to kni module, but not sure from build point of
view.

> 
> However,  no strong opinion either way.  
> 

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-dev] [PATCH] mk: fix kernel modules build dependency
  2018-03-29 18:21             ` Ferruh Yigit
@ 2018-03-29 18:43               ` Ferruh Yigit
  2018-03-30  8:32                 ` Thomas Monjalon
  0 siblings, 1 reply; 14+ messages in thread
From: Ferruh Yigit @ 2018-03-29 18:43 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: hemant.agrawal, dev

On 3/29/2018 7:21 PM, Ferruh Yigit wrote:
> On 3/29/2018 6:01 PM, Thomas Monjalon wrote:
>> 29/03/2018 18:50, Ferruh Yigit:
>>> On 3/29/2018 5:43 PM, Thomas Monjalon wrote:
>>>> 29/03/2018 18:38, Ferruh Yigit:
>>>>> On 3/29/2018 5:32 PM, Thomas Monjalon wrote:
>>>>>> 29/03/2018 17:48, Ferruh Yigit:
>>>>>>> On 3/29/2018 4:39 PM, Thomas Monjalon wrote:
>>>>>>>> Some kernel modules may need some header files to be "installed"
>>>>>>>> in the build directory.
>>>>>>>>
>>>>>>>> When running multiple threads of make, kernel modules can try to
>>>>>>>> be compiled before the lib headers are ready:
>>>>>>>> 	make -j3
>>>>>>>> 	kernel/linux/kni/kni_misc.c:19:37: fatal error:
>>>>>>>> 		exec-env/rte_kni_common.h: No such file or directory
>>>>>>>
>>>>>>> Is there a reason to keep header in eal when module itself moved into kernel?
>>>>>>
>>>>>> It seems you missed my comment below:
>>>>>>
>>>>>> On a related note, this header file
>>>>>>         lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
>>>>>> could be moved to lib/librte_kni/
>>>>>> Opinion?
>>>>>
>>>>> Ahh, yes we are saying same thing.
>>>>> But not sure if it should go under lib/librte_kni/ or kernel/linux/kni/?
>>>>> I lean to kernel/linux/kni/.
>>>>
>>>> Why in kernel/?
>>>>
>>>> Logically, kernel/ depends on lib/ but not the reverse.
>>>>
>>>> And regarding the licensing, we avoid BSD files in Linux modules.
>>>
>>> From functionality point of view, module provides the functionality and it
>>> should provide the header, this can be all subjective tough :)
>>>
>>> Or in other words, if you have the kernel module, you can write another piece of
>>> userspace application (without using librte_kni) and it will be functional.
>>> But if you have the librte_kni only, it won't be functional on its own.
>>>
>>> Providing header with kernel enables other userspace app to user KNI.
>>
>> So you are saying we should reverse the dependency?
>> It would mean moving all headers used by kernel modules in kernel/ directory:
> 
> No, not talking about moving headers to kernel/ folder. But we can "liberate" J
> the kernel modules.
> 
> For KNI, rte_kni_common.h is shared between kernel and userspace, can't escape
> from it. But why this common header needs to depend other dpdk headers at all?
> Indeed commenting out rte_common and rte_config worked fine, it seem there is
> already no dependency.

Hemant is right, putting rte_kni_common makes build dependent to module build,
and module is more fragile.

I agree to move header to userspace library.

> 
> Same thing for igb_uio, why in needs to depend other dpdk headers?
> Following seems fixing the issue, yes it is duplication but I think that is OK:
>  -#include <rte_pci_dev_features.h>
>  +/*#include <rte_pci_dev_features.h>*/
>  +enum rte_intr_mode {
>  +       RTE_INTR_MODE_NONE = 0,
>  +       RTE_INTR_MODE_LEGACY,
>  +       RTE_INTR_MODE_MSI,
>  +       RTE_INTR_MODE_MSIX
>  +};
>  +#define RTE_INTR_MODE_NONE_NAME "none"
>  +#define RTE_INTR_MODE_LEGACY_NAME "legacy"
>  +#define RTE_INTR_MODE_MSI_NAME "msi"
>  +#define RTE_INTR_MODE_MSIX_NAME "msix"
> 
>> 	- rte_pci_dev_features.h
>> 	\- rte_pci_dev_feature_defs.h
>> 	- rte_kni_common.h
>> 	\- rte_common.h
>>
>> Are you sure?
>>
>>
> 

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-dev] [PATCH] mk: fix kernel modules build dependency
  2018-03-29 18:43               ` Ferruh Yigit
@ 2018-03-30  8:32                 ` Thomas Monjalon
  2018-03-30 10:15                   ` Ferruh Yigit
  0 siblings, 1 reply; 14+ messages in thread
From: Thomas Monjalon @ 2018-03-30  8:32 UTC (permalink / raw)
  To: Ferruh Yigit; +Cc: hemant.agrawal, dev

29/03/2018 20:43, Ferruh Yigit:
> On 3/29/2018 7:21 PM, Ferruh Yigit wrote:
> > On 3/29/2018 6:01 PM, Thomas Monjalon wrote:
> >> 29/03/2018 18:50, Ferruh Yigit:
> >>> On 3/29/2018 5:43 PM, Thomas Monjalon wrote:
> >>>> 29/03/2018 18:38, Ferruh Yigit:
> >>>>> On 3/29/2018 5:32 PM, Thomas Monjalon wrote:
> >>>>>> 29/03/2018 17:48, Ferruh Yigit:
> >>>>>>> On 3/29/2018 4:39 PM, Thomas Monjalon wrote:
> >>>>>>>> Some kernel modules may need some header files to be "installed"
> >>>>>>>> in the build directory.
> >>>>>>>>
> >>>>>>>> When running multiple threads of make, kernel modules can try to
> >>>>>>>> be compiled before the lib headers are ready:
> >>>>>>>> 	make -j3
> >>>>>>>> 	kernel/linux/kni/kni_misc.c:19:37: fatal error:
> >>>>>>>> 		exec-env/rte_kni_common.h: No such file or directory
> >>>>>>>
> >>>>>>> Is there a reason to keep header in eal when module itself moved into kernel?
> >>>>>>
> >>>>>> It seems you missed my comment below:
> >>>>>>
> >>>>>> On a related note, this header file
> >>>>>>         lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
> >>>>>> could be moved to lib/librte_kni/
> >>>>>> Opinion?
> >>>>>
> >>>>> Ahh, yes we are saying same thing.
> >>>>> But not sure if it should go under lib/librte_kni/ or kernel/linux/kni/?
> >>>>> I lean to kernel/linux/kni/.
> >>>>
> >>>> Why in kernel/?
> >>>>
> >>>> Logically, kernel/ depends on lib/ but not the reverse.
> >>>>
> >>>> And regarding the licensing, we avoid BSD files in Linux modules.
> >>>
> >>> From functionality point of view, module provides the functionality and it
> >>> should provide the header, this can be all subjective tough :)
> >>>
> >>> Or in other words, if you have the kernel module, you can write another piece of
> >>> userspace application (without using librte_kni) and it will be functional.
> >>> But if you have the librte_kni only, it won't be functional on its own.
> >>>
> >>> Providing header with kernel enables other userspace app to user KNI.
> >>
> >> So you are saying we should reverse the dependency?
> >> It would mean moving all headers used by kernel modules in kernel/ directory:
> > 
> > No, not talking about moving headers to kernel/ folder. But we can "liberate" J
> > the kernel modules.
> > 
> > For KNI, rte_kni_common.h is shared between kernel and userspace, can't escape
> > from it. But why this common header needs to depend other dpdk headers at all?
> > Indeed commenting out rte_common and rte_config worked fine, it seem there is
> > already no dependency.
> 
> Hemant is right, putting rte_kni_common makes build dependent to module build,
> and module is more fragile.
> 
> I agree to move header to userspace library.

Does it mean you ack this patch?

Do you want to make a patch to move the header from EAL to librte_kni?

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-dev] [PATCH] mk: fix kernel modules build dependency
  2018-03-30  8:32                 ` Thomas Monjalon
@ 2018-03-30 10:15                   ` Ferruh Yigit
  2018-03-30 11:03                     ` Thomas Monjalon
  0 siblings, 1 reply; 14+ messages in thread
From: Ferruh Yigit @ 2018-03-30 10:15 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: hemant.agrawal, dev

On 3/30/2018 9:32 AM, Thomas Monjalon wrote:
> 29/03/2018 20:43, Ferruh Yigit:
>> On 3/29/2018 7:21 PM, Ferruh Yigit wrote:
>>> On 3/29/2018 6:01 PM, Thomas Monjalon wrote:
>>>> 29/03/2018 18:50, Ferruh Yigit:
>>>>> On 3/29/2018 5:43 PM, Thomas Monjalon wrote:
>>>>>> 29/03/2018 18:38, Ferruh Yigit:
>>>>>>> On 3/29/2018 5:32 PM, Thomas Monjalon wrote:
>>>>>>>> 29/03/2018 17:48, Ferruh Yigit:
>>>>>>>>> On 3/29/2018 4:39 PM, Thomas Monjalon wrote:
>>>>>>>>>> Some kernel modules may need some header files to be "installed"
>>>>>>>>>> in the build directory.
>>>>>>>>>>
>>>>>>>>>> When running multiple threads of make, kernel modules can try to
>>>>>>>>>> be compiled before the lib headers are ready:
>>>>>>>>>> 	make -j3
>>>>>>>>>> 	kernel/linux/kni/kni_misc.c:19:37: fatal error:
>>>>>>>>>> 		exec-env/rte_kni_common.h: No such file or directory
>>>>>>>>>
>>>>>>>>> Is there a reason to keep header in eal when module itself moved into kernel?
>>>>>>>>
>>>>>>>> It seems you missed my comment below:
>>>>>>>>
>>>>>>>> On a related note, this header file
>>>>>>>>         lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
>>>>>>>> could be moved to lib/librte_kni/
>>>>>>>> Opinion?
>>>>>>>
>>>>>>> Ahh, yes we are saying same thing.
>>>>>>> But not sure if it should go under lib/librte_kni/ or kernel/linux/kni/?
>>>>>>> I lean to kernel/linux/kni/.
>>>>>>
>>>>>> Why in kernel/?
>>>>>>
>>>>>> Logically, kernel/ depends on lib/ but not the reverse.
>>>>>>
>>>>>> And regarding the licensing, we avoid BSD files in Linux modules.
>>>>>
>>>>> From functionality point of view, module provides the functionality and it
>>>>> should provide the header, this can be all subjective tough :)
>>>>>
>>>>> Or in other words, if you have the kernel module, you can write another piece of
>>>>> userspace application (without using librte_kni) and it will be functional.
>>>>> But if you have the librte_kni only, it won't be functional on its own.
>>>>>
>>>>> Providing header with kernel enables other userspace app to user KNI.
>>>>
>>>> So you are saying we should reverse the dependency?
>>>> It would mean moving all headers used by kernel modules in kernel/ directory:
>>>
>>> No, not talking about moving headers to kernel/ folder. But we can "liberate" J
>>> the kernel modules.
>>>
>>> For KNI, rte_kni_common.h is shared between kernel and userspace, can't escape
>>> from it. But why this common header needs to depend other dpdk headers at all?
>>> Indeed commenting out rte_common and rte_config worked fine, it seem there is
>>> already no dependency.
>>
>> Hemant is right, putting rte_kni_common makes build dependent to module build,
>> and module is more fragile.
>>
>> I agree to move header to userspace library.
> 
> Does it mean you ack this patch?

yep,
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>

> 
> Do you want to make a patch to move the header from EAL to librte_kni?
> 
> 
> 

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-dev] [PATCH] mk: fix kernel modules build dependency
  2018-03-30 10:15                   ` Ferruh Yigit
@ 2018-03-30 11:03                     ` Thomas Monjalon
  0 siblings, 0 replies; 14+ messages in thread
From: Thomas Monjalon @ 2018-03-30 11:03 UTC (permalink / raw)
  To: Ferruh Yigit; +Cc: dev, hemant.agrawal

30/03/2018 12:15, Ferruh Yigit:
> On 3/30/2018 9:32 AM, Thomas Monjalon wrote:
> > 29/03/2018 20:43, Ferruh Yigit:
> >> On 3/29/2018 7:21 PM, Ferruh Yigit wrote:
> >>> On 3/29/2018 6:01 PM, Thomas Monjalon wrote:
> >>>> 29/03/2018 18:50, Ferruh Yigit:
> >>>>> On 3/29/2018 5:43 PM, Thomas Monjalon wrote:
> >>>>>> 29/03/2018 18:38, Ferruh Yigit:
> >>>>>>> On 3/29/2018 5:32 PM, Thomas Monjalon wrote:
> >>>>>>>> 29/03/2018 17:48, Ferruh Yigit:
> >>>>>>>>> On 3/29/2018 4:39 PM, Thomas Monjalon wrote:
> >>>>>>>>>> Some kernel modules may need some header files to be "installed"
> >>>>>>>>>> in the build directory.
> >>>>>>>>>>
> >>>>>>>>>> When running multiple threads of make, kernel modules can try to
> >>>>>>>>>> be compiled before the lib headers are ready:
> >>>>>>>>>> 	make -j3
> >>>>>>>>>> 	kernel/linux/kni/kni_misc.c:19:37: fatal error:
> >>>>>>>>>> 		exec-env/rte_kni_common.h: No such file or directory
> >>>>>>>>>
> >>>>>>>>> Is there a reason to keep header in eal when module itself moved into kernel?
> >>>>>>>>
> >>>>>>>> It seems you missed my comment below:
> >>>>>>>>
> >>>>>>>> On a related note, this header file
> >>>>>>>>         lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
> >>>>>>>> could be moved to lib/librte_kni/
> >>>>>>>> Opinion?
> >>>>>>>
> >>>>>>> Ahh, yes we are saying same thing.
> >>>>>>> But not sure if it should go under lib/librte_kni/ or kernel/linux/kni/?
> >>>>>>> I lean to kernel/linux/kni/.
> >>>>>>
> >>>>>> Why in kernel/?
> >>>>>>
> >>>>>> Logically, kernel/ depends on lib/ but not the reverse.
> >>>>>>
> >>>>>> And regarding the licensing, we avoid BSD files in Linux modules.
> >>>>>
> >>>>> From functionality point of view, module provides the functionality and it
> >>>>> should provide the header, this can be all subjective tough :)
> >>>>>
> >>>>> Or in other words, if you have the kernel module, you can write another piece of
> >>>>> userspace application (without using librte_kni) and it will be functional.
> >>>>> But if you have the librte_kni only, it won't be functional on its own.
> >>>>>
> >>>>> Providing header with kernel enables other userspace app to user KNI.
> >>>>
> >>>> So you are saying we should reverse the dependency?
> >>>> It would mean moving all headers used by kernel modules in kernel/ directory:
> >>>
> >>> No, not talking about moving headers to kernel/ folder. But we can "liberate" J
> >>> the kernel modules.
> >>>
> >>> For KNI, rte_kni_common.h is shared between kernel and userspace, can't escape
> >>> from it. But why this common header needs to depend other dpdk headers at all?
> >>> Indeed commenting out rte_common and rte_config worked fine, it seem there is
> >>> already no dependency.
> >>
> >> Hemant is right, putting rte_kni_common makes build dependent to module build,
> >> and module is more fragile.
> >>
> >> I agree to move header to userspace library.
> > 
> > Does it mean you ack this patch?
> 
> yep,
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>

Applied, thanks

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2018-03-30 11:03 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-29 15:39 [dpdk-dev] [PATCH] mk: fix kernel modules build dependency Thomas Monjalon
2018-03-29 15:48 ` Ferruh Yigit
2018-03-29 16:32   ` Thomas Monjalon
2018-03-29 16:38     ` Ferruh Yigit
2018-03-29 16:43       ` Thomas Monjalon
2018-03-29 16:50         ` Ferruh Yigit
2018-03-29 17:01           ` Thomas Monjalon
2018-03-29 18:12             ` Hemant Agrawal
2018-03-29 18:28               ` Ferruh Yigit
2018-03-29 18:21             ` Ferruh Yigit
2018-03-29 18:43               ` Ferruh Yigit
2018-03-30  8:32                 ` Thomas Monjalon
2018-03-30 10:15                   ` Ferruh Yigit
2018-03-30 11:03                     ` Thomas Monjalon

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).