[dpdk-dev] Question about adding a new EAL

[dpdk-dev] Question about adding a new EAL

[Alexandru Ciobotaru]

Greetings,

I'm currently checking on how to add new EAL "app" to the DPDK so I started
by adding a new "xyzapp" next to "linuxapp" and "bsdapp".
Now, I would probably expect to make this new EAL mainline compliant on
day, and to avoid future headaches, the plan is to avoid modifying things
outside of my "xyzapp".
And thus, the first adaptation issue has arrived:

EAL is designed so that I can re-implement the "common" source files into
my "xyzapp" but how would I override the "include/rte_xyz.h" headers from
the "common" part of the EAL library (e.g.
librte_eal/common/include/rte_eal.h)? Some of the includes in these headers
are currently N/A to my toolchain (via CROSS=) or to my executive
environment.
For example I do not have <sched.h> or <sys/queue.h> which are currently
included in some EAL API headers.
Should more work into making the "common" part truly generic be put into
this?
Is the current EAL API frozen for compatibility reasons? Any "next" branch
where such modifications are accepted?
Or, is there a straight method of enforcing my "xyzapp" symlinked EAL
headers in the build directory without modifying the "common" Makefile?

Thank you,
Alex

Re: [dpdk-dev] Question about adding a new EAL

[Wiles, Keith]

On May 22, 2018, at 2:23 PM, Alexandru Ciobotaru <alex.ciobotaru@gmail.com<mailto:alex.ciobotaru@gmail.com>> wrote:

Greetings,

I can not answer all of your questions, but maybe a few.


I'm currently checking on how to add new EAL "app" to the DPDK so I started
by adding a new "xyzapp" next to "linuxapp" and "bsdapp".
Now, I would probably expect to make this new EAL mainline compliant on
day, and to avoid future headaches, the plan is to avoid modifying things
outside of my "xyzapp".
And thus, the first adaptation issue has arrived:

EAL is designed so that I can re-implement the "common" source files into
my "xyzapp" but how would I override the "include/rte_xyz.h" headers from
the "common" part of the EAL library (e.g.
librte_eal/common/include/rte_eal.h)? Some of the includes in these headers
are currently N/A to my toolchain (via CROSS=) or to my executive
environment.

Normally, these types of differences are just empty variables or something that allows the system build even when you do not support it.

For example I do not have <sched.h> or <sys/queue.h> which are currently
included in some EAL API headers.

Maybe you should make simple empty headers, to work around those headers. I am sure it would be easier, but maybe someone has a better idea.

Should more work into making the "common" part truly generic be put into
this?

We always like to see patches to make the EAL simpler to maintain, so please introduce a patch.

Is the current EAL API frozen for compatibility reasons? Any "next" branch
where such modifications are accepted?

Changing a EAL API is really discouraged as it effect a lot of places. But we do have a method to change exposed APIs. It will take two releases to get your change into DPDK the first release gives notice and the second one allows the API to exist in the code. You can read more abort the process here: http://dpdk.org/dev make sure you read it all :-)

Or, is there a straight method of enforcing my "xyzapp" symlinked EAL
headers in the build directory without modifying the "common" Makefile?

You should avoid symlinks in the main repo directories as they are difficult to maintain and some systems do not support them.


Thank you,
Alex

Let us know if you need anything else.

Regards,
Keith

Re: [dpdk-dev] Question about adding a new EAL

[Wiles, Keith]

Must use text only :-( darn mail program


> On May 22, 2018, at 2:23 PM, Alexandru Ciobotaru <alex.ciobotaru@gmail.com> wrote:
> 
> Greetings,

I can not answer all of your questions, but maybe a few.
> 

> I'm currently checking on how to add new EAL "app" to the DPDK so I started
> by adding a new "xyzapp" next to "linuxapp" and "bsdapp".
> Now, I would probably expect to make this new EAL mainline compliant on
> day, and to avoid future headaches, the plan is to avoid modifying things
> outside of my "xyzapp".
> And thus, the first adaptation issue has arrived:
> 
> EAL is designed so that I can re-implement the "common" source files into
> my "xyzapp" but how would I override the "include/rte_xyz.h" headers from
> the "common" part of the EAL library (e.g.
> librte_eal/common/include/rte_eal.h)? Some of the includes in these headers
> are currently N/A to my toolchain (via CROSS=) or to my executive
> environment.

Normally, these types of differences are just empty variables or something that allows the system build even when you do not support it.

> For example I do not have <sched.h> or <sys/queue.h> which are currently
> included in some EAL API headers.

Maybe you should make simple empty headers, to work around those headers. I am sure it would be easier, but maybe someone has a better idea.

> Should more work into making the "common" part truly generic be put into
> this?

We always like to see patches to make the EAL simpler to maintain, so please introduce a patch.

> Is the current EAL API frozen for compatibility reasons? Any "next" branch
> where such modifications are accepted?

Changing a EAL API is really discouraged as it effect a lot of places. But we do have a method to change exposed APIs. It will take two releases to get your change into DPDK the first release gives notice and the second one allows the API to exist in the code. You can read more abort the process here: http://dpdk.org/dev make sure you read it all :-)

> Or, is there a straight method of enforcing my "xyzapp" symlinked EAL
> headers in the build directory without modifying the "common" Makefile?

You should avoid symlinks in the main repo directories as they are difficult to maintain and some systems do not support them.

You may want to do an RFC email subject to discuss your ideas on changing EAL code first to eliminate extra work.

> 
> Thank you,
> Alex

Regards,
Keith

Re: [dpdk-dev] Question about adding a new EAL

[Thomas Monjalon]

22/05/2018 21:59, Wiles, Keith:
> You may want to do an RFC email subject to discuss your ideas on changing EAL code first to eliminate extra work.

Yes, definitely, RFC with first ideas can help to discuss.

One more pointer, Windows support in progress:
	http://dpdk.org/browse/draft/dpdk-draft-windows/

Re: [dpdk-dev] Question about adding a new EAL

[Alex Ciobotaru]

Guys, thank you for the info so far (sorry about the HTML thing).
I will put some further insight/closure into this thread.
So, my query started from the fact that when developing a new EAL in DPDK using an external toolchain and/or for a new OS, the "common" (generic) part of the EAL is actually Linux/BSD bound:

/...// START OF EXCERPT////dpdk/build/include/rte_eal.h:15:19: fatal error: sched.h: No such file 
or directory////#include <sched.h>////^////compilation terminated.////...// END OF EXCERPT///
Above I'm building (via cross toolchain) my new "xyzapp" (with its own EAL rte_*.c files) but with the inherited common headers (since the EAL/common master Makefile makes build-generated symbolic links in my build dir).
So for now, I identified two quick options:
- Modify the EAL headers where needed. In this case, I would remove includes such as ones above from the EAL headers, but it would probably break current supported EALs
- Modify the EAL build sub-system to export my "xyzapp" (re)implemented EAL headers instead of the common ones (keeping the API, but fixing the "app" toolchain/exec-env dependencies).
   Basically all P headers that define the EAL would be split into M "common/generic" headers and N "app" re-implemented headers.

Thank you!
Alex

On 22-May-18 11:18 PM, Thomas Monjalon wrote:

> 22/05/2018 21:59, Wiles, Keith:
>> You may want to do an RFC email subject to discuss your ideas on changing EAL code first to eliminate extra work.
> Yes, definitely, RFC with first ideas can help to discuss.
>
> One more pointer, Windows support in progress:
> 	http://dpdk.org/browse/draft/dpdk-draft-windows/
>
>

Re: [dpdk-dev] Question about adding a new EAL

[Thomas Monjalon]

22/05/2018 22:56, Alex Ciobotaru:
> Guys, thank you for the info so far (sorry about the HTML thing).
> I will put some further insight/closure into this thread.
> So, my query started from the fact that when developing a new EAL
> in DPDK using an external toolchain and/or for a new OS,
> the "common" (generic) part of the EAL is actually Linux/BSD bound:
> 
> ...// START OF EXCERPT
> dpdk/build/include/rte_eal.h:15:19: fatal error:
> sched.h: No such file or directory

So you want to port DPDK to a non-POSIX OS?

If it is considered an interesting OS, we could move some POSIX parts
out of the common files.