[dpdk-dev] eal: change init macro as exec environment specific
Checks
Commit Message
baremetal execution environments may have a different
method to enable RTE_INIT instead of using compiler
constructor scheme. Move RTE_INIT* definition under
exec-env to support different execution environments.
Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
---
app/test-eventdev/evt_test.h | 2 +-
lib/librte_eal/bsdapp/eal/Makefile | 2 +-
.../bsdapp/eal/include/exec-env/rte_eal.h | 51 ++++++++++++++++++++++
lib/librte_eal/common/eal_common_log.c | 2 +
lib/librte_eal/common/include/rte_bus.h | 2 +
lib/librte_eal/common/include/rte_eal.h | 6 ---
lib/librte_eal/common/include/rte_tailq.h | 2 +
lib/librte_eal/linuxapp/eal/Makefile | 2 +-
.../linuxapp/eal/include/exec-env/rte_eal.h | 51 ++++++++++++++++++++++
9 files changed, 111 insertions(+), 9 deletions(-)
create mode 100644 lib/librte_eal/bsdapp/eal/include/exec-env/rte_eal.h
create mode 100644 lib/librte_eal/linuxapp/eal/include/exec-env/rte_eal.h
Comments
07/08/2017 14:04, Jerin Jacob:
> baremetal execution environments may have a different
> method to enable RTE_INIT instead of using compiler
> constructor scheme. Move RTE_INIT* definition under
> exec-env to support different execution environments.
>
> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> ---
> app/test-eventdev/evt_test.h | 2 +-
> lib/librte_eal/bsdapp/eal/Makefile | 2 +-
> .../bsdapp/eal/include/exec-env/rte_eal.h | 51 ++++++++++++++++++++++
> lib/librte_eal/common/eal_common_log.c | 2 +
> lib/librte_eal/common/include/rte_bus.h | 2 +
> lib/librte_eal/common/include/rte_eal.h | 6 ---
> lib/librte_eal/common/include/rte_tailq.h | 2 +
> lib/librte_eal/linuxapp/eal/Makefile | 2 +-
> .../linuxapp/eal/include/exec-env/rte_eal.h | 51 ++++++++++++++++++++++
> 9 files changed, 111 insertions(+), 9 deletions(-)
> create mode 100644 lib/librte_eal/bsdapp/eal/include/exec-env/rte_eal.h
> create mode 100644 lib/librte_eal/linuxapp/eal/include/exec-env/rte_eal.h
I am not a big fan of duplicating code for Linux and BSD.
Maybe we should have different splits and include a common file
in Linux and BSD?
I feel it would be easier to think about the split when adding
a new environment.
It is also an open question whether we want to support (again) some
bare metal environments.
-----Original Message-----
> Date: Wed, 11 Oct 2017 15:02:51 +0200
> From: Thomas Monjalon <thomas@monjalon.net>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> Cc: dev@dpdk.org, bruce.richardson@intel.com
> Subject: Re: [dpdk-dev] [PATCH] eal: change init macro as exec environment
> specific
>
> 07/08/2017 14:04, Jerin Jacob:
> > baremetal execution environments may have a different
> > method to enable RTE_INIT instead of using compiler
> > constructor scheme. Move RTE_INIT* definition under
> > exec-env to support different execution environments.
> >
> > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > ---
> > app/test-eventdev/evt_test.h | 2 +-
> > lib/librte_eal/bsdapp/eal/Makefile | 2 +-
> > .../bsdapp/eal/include/exec-env/rte_eal.h | 51 ++++++++++++++++++++++
> > lib/librte_eal/common/eal_common_log.c | 2 +
> > lib/librte_eal/common/include/rte_bus.h | 2 +
> > lib/librte_eal/common/include/rte_eal.h | 6 ---
> > lib/librte_eal/common/include/rte_tailq.h | 2 +
> > lib/librte_eal/linuxapp/eal/Makefile | 2 +-
> > .../linuxapp/eal/include/exec-env/rte_eal.h | 51 ++++++++++++++++++++++
> > 9 files changed, 111 insertions(+), 9 deletions(-)
> > create mode 100644 lib/librte_eal/bsdapp/eal/include/exec-env/rte_eal.h
> > create mode 100644 lib/librte_eal/linuxapp/eal/include/exec-env/rte_eal.h
>
> I am not a big fan of duplicating code for Linux and BSD.
>
> Maybe we should have different splits and include a common file
> in Linux and BSD?
OK. This is doable.
>
> I feel it would be easier to think about the split when adding
> a new environment.
> It is also an open question whether we want to support (again) some
> bare metal environments.
IMO, A factor could be, how much we are OK to change?
Our internal prototype implementation for a bare metal environment
shows things are already in place and may need minor changes like this to
accommodate a bare metal execution environment(accounting the latest
changes of moving pci to driver/pci/..)
If no one care about need for such abstraction then we could drop this
patch. We can always keep local copy of such patches in our internal
tree. I thought to upstream it as it may be useful for someone else and
it is easy for us maintain if changes are in
lib/librte_eal/<new environment>/eal/ and drivers/*/
On 10/11/2017 3:33 PM, jerin.jacob at caviumnetworks.com (Jerin Jacob) wrote:
> -----Original Message-----
>> Date: Wed, 11 Oct 2017 15:02:51 +0200
>> From: Thomas Monjalon <thomas at monjalon.net>
>> To: Jerin Jacob <jerin.jacob at caviumnetworks.com>
>> Cc: dev at dpdk.org, bruce.richardson at intel.com
>> Subject: Re: [dpdk-dev] [PATCH] eal: change init macro as exec environment
>> specific
>>
>> 07/08/2017 14:04, Jerin Jacob:
>>> baremetal execution environments may have a different
>>> method to enable RTE_INIT instead of using compiler
>>> constructor scheme. Move RTE_INIT* definition under
>>> exec-env to support different execution environments.
>>>
>>> Signed-off-by: Jerin Jacob <jerin.jacob at caviumnetworks.com>
>>> ---
>>> app/test-eventdev/evt_test.h | 2 +-
>>> lib/librte_eal/bsdapp/eal/Makefile | 2 +-
>>> .../bsdapp/eal/include/exec-env/rte_eal.h | 51 ++++++++++++++++++++++
>>> lib/librte_eal/common/eal_common_log.c | 2 +
>>> lib/librte_eal/common/include/rte_bus.h | 2 +
>>> lib/librte_eal/common/include/rte_eal.h | 6 ---
>>> lib/librte_eal/common/include/rte_tailq.h | 2 +
>>> lib/librte_eal/linuxapp/eal/Makefile | 2 +-
>>> .../linuxapp/eal/include/exec-env/rte_eal.h | 51 ++++++++++++++++++++++
>>> 9 files changed, 111 insertions(+), 9 deletions(-)
>>> create mode 100644 lib/librte_eal/bsdapp/eal/include/exec-env/rte_eal.h
>>> create mode 100644 lib/librte_eal/linuxapp/eal/include/exec-env/rte_eal.h
>>
>> I am not a big fan of duplicating code for Linux and BSD.
>>
>> Maybe we should have different splits and include a common file
>> in Linux and BSD?
>
> OK. This is doable.
>
>>
>> I feel it would be easier to think about the split when adding
>> a new environment.
>> It is also an open question whether we want to support (again) some
>> bare metal environments.
>
> IMO, A factor could be, how much we are OK to change?
>
> Our internal prototype implementation for a bare metal environment
> shows things are already in place and may need minor changes like this to
> accommodate a bare metal execution environment(accounting the latest
> changes of moving pci to driver/pci/..)
>
> If no one care about need for such abstraction then we could drop this
> patch. We can always keep local copy of such patches in our internal
> tree. I thought to upstream it as it may be useful for someone else and
> it is easy for us maintain if changes are in
> lib/librte_eal/<new environment>/eal/ and drivers/*/
Hi Jerin, Thomas,
This is an old patch, the abstraction seems good idea but it comes with a
duplication.
Is there an intention to continue the work? Are we waiting for any decision?
Any objection to mark it as rejected?
Thanks,
ferruh
On 3/1/2019 5:05 PM, Ferruh Yigit wrote:
> On 10/11/2017 3:33 PM, jerin.jacob at caviumnetworks.com (Jerin Jacob) wrote:
>> -----Original Message-----
>>> Date: Wed, 11 Oct 2017 15:02:51 +0200
>>> From: Thomas Monjalon <thomas at monjalon.net>
>>> To: Jerin Jacob <jerin.jacob at caviumnetworks.com>
>>> Cc: dev at dpdk.org, bruce.richardson at intel.com
>>> Subject: Re: [dpdk-dev] [PATCH] eal: change init macro as exec environment
>>> specific
>>>
>>> 07/08/2017 14:04, Jerin Jacob:
>>>> baremetal execution environments may have a different
>>>> method to enable RTE_INIT instead of using compiler
>>>> constructor scheme. Move RTE_INIT* definition under
>>>> exec-env to support different execution environments.
>>>>
>>>> Signed-off-by: Jerin Jacob <jerin.jacob at caviumnetworks.com>
>>>> ---
>>>> app/test-eventdev/evt_test.h | 2 +-
>>>> lib/librte_eal/bsdapp/eal/Makefile | 2 +-
>>>> .../bsdapp/eal/include/exec-env/rte_eal.h | 51 ++++++++++++++++++++++
>>>> lib/librte_eal/common/eal_common_log.c | 2 +
>>>> lib/librte_eal/common/include/rte_bus.h | 2 +
>>>> lib/librte_eal/common/include/rte_eal.h | 6 ---
>>>> lib/librte_eal/common/include/rte_tailq.h | 2 +
>>>> lib/librte_eal/linuxapp/eal/Makefile | 2 +-
>>>> .../linuxapp/eal/include/exec-env/rte_eal.h | 51 ++++++++++++++++++++++
>>>> 9 files changed, 111 insertions(+), 9 deletions(-)
>>>> create mode 100644 lib/librte_eal/bsdapp/eal/include/exec-env/rte_eal.h
>>>> create mode 100644 lib/librte_eal/linuxapp/eal/include/exec-env/rte_eal.h
>>>
>>> I am not a big fan of duplicating code for Linux and BSD.
>>>
>>> Maybe we should have different splits and include a common file
>>> in Linux and BSD?
>>
>> OK. This is doable.
>>
>>>
>>> I feel it would be easier to think about the split when adding
>>> a new environment.
>>> It is also an open question whether we want to support (again) some
>>> bare metal environments.
>>
>> IMO, A factor could be, how much we are OK to change?
>>
>> Our internal prototype implementation for a bare metal environment
>> shows things are already in place and may need minor changes like this to
>> accommodate a bare metal execution environment(accounting the latest
>> changes of moving pci to driver/pci/..)
>>
>> If no one care about need for such abstraction then we could drop this
>> patch. We can always keep local copy of such patches in our internal
>> tree. I thought to upstream it as it may be useful for someone else and
>> it is easy for us maintain if changes are in
>> lib/librte_eal/<new environment>/eal/ and drivers/*/
> Hi Jerin, Thomas,
>
> This is an old patch, the abstraction seems good idea but it comes with a
> duplication.
>
> Is there an intention to continue the work? Are we waiting for any decision?
> Any objection to mark it as rejected?
For reference, mentioned patch:
https://patches.dpdk.org/patch/27474/
>
> Thanks,
> ferruh
>
01/03/2019 18:05, Ferruh Yigit:
> On 10/11/2017 3:33 PM, jerin.jacob at caviumnetworks.com (Jerin Jacob) wrote:
> > From: Thomas Monjalon <thomas at monjalon.net>
> >> 07/08/2017 14:04, Jerin Jacob:
> >>> baremetal execution environments may have a different
> >>> method to enable RTE_INIT instead of using compiler
> >>> constructor scheme. Move RTE_INIT* definition under
> >>> exec-env to support different execution environments.
> >>>
> >>> Signed-off-by: Jerin Jacob <jerin.jacob at caviumnetworks.com>
> >>> ---
> >>> app/test-eventdev/evt_test.h | 2 +-
> >>> lib/librte_eal/bsdapp/eal/Makefile | 2 +-
> >>> .../bsdapp/eal/include/exec-env/rte_eal.h | 51 ++++++++++++++++++++++
> >>> lib/librte_eal/common/eal_common_log.c | 2 +
> >>> lib/librte_eal/common/include/rte_bus.h | 2 +
> >>> lib/librte_eal/common/include/rte_eal.h | 6 ---
> >>> lib/librte_eal/common/include/rte_tailq.h | 2 +
> >>> lib/librte_eal/linuxapp/eal/Makefile | 2 +-
> >>> .../linuxapp/eal/include/exec-env/rte_eal.h | 51 ++++++++++++++++++++++
> >>> 9 files changed, 111 insertions(+), 9 deletions(-)
> >>> create mode 100644 lib/librte_eal/bsdapp/eal/include/exec-env/rte_eal.h
> >>> create mode 100644 lib/librte_eal/linuxapp/eal/include/exec-env/rte_eal.h
> >>
> >> I am not a big fan of duplicating code for Linux and BSD.
> >>
> >> Maybe we should have different splits and include a common file
> >> in Linux and BSD?
> >
> > OK. This is doable.
> >
> >>
> >> I feel it would be easier to think about the split when adding
> >> a new environment.
> >> It is also an open question whether we want to support (again) some
> >> bare metal environments.
> >
> > IMO, A factor could be, how much we are OK to change?
> >
> > Our internal prototype implementation for a bare metal environment
> > shows things are already in place and may need minor changes like this to
> > accommodate a bare metal execution environment(accounting the latest
> > changes of moving pci to driver/pci/..)
> >
> > If no one care about need for such abstraction then we could drop this
> > patch. We can always keep local copy of such patches in our internal
> > tree. I thought to upstream it as it may be useful for someone else and
> > it is easy for us maintain if changes are in
> > lib/librte_eal/<new environment>/eal/ and drivers/*/
> Hi Jerin, Thomas,
>
> This is an old patch, the abstraction seems good idea but it comes with a
> duplication.
>
> Is there an intention to continue the work? Are we waiting for any decision?
> Any objection to mark it as rejected?
I am not sure there is a real desire to make DPDK
ready for bare-metal (back again).
If any of you are aware of a real use-case, we can re-consider.
On Fri, 2019-03-01 at 18:28 +0100, Thomas Monjalon wrote:
> External Email
>
> -------------------------------------------------------------------
> ---
> 01/03/2019 18:05, Ferruh Yigit:
> > On 10/11/2017 3:33 PM, jerin.jacob at caviumnetworks.com (Jerin
> > Jacob) wrote:
> > > From: Thomas Monjalon <thomas at monjalon.net>
> > > > 07/08/2017 14:04, Jerin Jacob:
> > > > > baremetal execution environments may have a different
> > > > > method to enable RTE_INIT instead of using compiler
> > > > > constructor scheme. Move RTE_INIT* definition under
> > > > > exec-env to support different execution environments.
> > > > >
> > > > > Signed-off-by: Jerin Jacob <jerin.jacob at
> > > > > caviumnetworks.com>
> > > > > ---
> > > > > app/test-eventdev/evt_test.h | 2 +-
> > > > > lib/librte_eal/bsdapp/eal/Makefile | 2 +-
> > > > > .../bsdapp/eal/include/exec-env/rte_eal.h | 51
> > > > > ++++++++++++++++++++++
> > > > > lib/librte_eal/common/eal_common_log.c | 2 +
> > > > > lib/librte_eal/common/include/rte_bus.h | 2 +
> > > > > lib/librte_eal/common/include/rte_eal.h | 6 ---
> > > > > lib/librte_eal/common/include/rte_tailq.h | 2 +
> > > > > lib/librte_eal/linuxapp/eal/Makefile | 2 +-
> > > > > .../linuxapp/eal/include/exec-env/rte_eal.h | 51
> > > > > ++++++++++++++++++++++
> > > > > 9 files changed, 111 insertions(+), 9 deletions(-)
> > > > > create mode 100644 lib/librte_eal/bsdapp/eal/include/exec-
> > > > > env/rte_eal.h
> > > > > create mode 100644 lib/librte_eal/linuxapp/eal/include/exec-
> > > > > env/rte_eal.h
> > > >
> > > > I am not a big fan of duplicating code for Linux and BSD.
> > > >
> > > > Maybe we should have different splits and include a common file
> > > > in Linux and BSD?
> > >
> > > OK. This is doable.
> > >
> > > > I feel it would be easier to think about the split when adding
> > > > a new environment.
> > > > It is also an open question whether we want to support (again)
> > > > some
> > > > bare metal environments.
> > >
> > > IMO, A factor could be, how much we are OK to change?
> > >
> > > Our internal prototype implementation for a bare metal
> > > environment
> > > shows things are already in place and may need minor changes like
> > > this to
> > > accommodate a bare metal execution environment(accounting the
> > > latest
> > > changes of moving pci to driver/pci/..)
> > >
> > > If no one care about need for such abstraction then we could drop
> > > this
> > > patch. We can always keep local copy of such patches in our
> > > internal
> > > tree. I thought to upstream it as it may be useful for someone
> > > else and
> > > it is easy for us maintain if changes are in
> > > lib/librte_eal/<new environment>/eal/ and drivers/*/
> > Hi Jerin, Thomas,
> >
> > This is an old patch, the abstraction seems good idea but it comes
> > with a
> > duplication.
> >
> > Is there an intention to continue the work? Are we waiting for any
> > decision?
> > Any objection to mark it as rejected?
>
> I am not sure there is a real desire to make DPDK
> ready for bare-metal (back again).
> If any of you are aware of a real use-case, we can re-consider.
Some of the usecases:
# PCIe endpoint mode aka Smart NIC(Where DPDK runs on PCIe card), May
not need to waste one core for Linux. Specially Smart NIC market has
less number of cores.
On the endpoint side, It treats as FW so customer may not have access
to so nobdoy cares it is Linux or baremetal so may need to waste one
core for Linux
# VM case, it possible to have bare metal guest just to save one a
logical core for Linux
# Some of the RTOS like Zephyr already provide TCP/IP stack and good
subsystems for specific usecases.
# We are using DPDK for pre silicon validation for SoC mode. Bringing
up linux on emulator takes ages, Baremetal can be used for Harware
verification too.
IMO, As long as it not limiting the a feature of Linux app, Why not to
allow baremetal? I agree with code duplication. I think, it can be
fixed easily, Other than that, Is there any concern?
Jerin
12/03/2019 20:25, Jerin Jacob Kollanukkaran:
> On Fri, 2019-03-01 at 18:28 +0100, Thomas Monjalon wrote:
> > External Email
> >
> > -------------------------------------------------------------------
> > ---
> > 01/03/2019 18:05, Ferruh Yigit:
> > > On 10/11/2017 3:33 PM, jerin.jacob at caviumnetworks.com (Jerin
> > > Jacob) wrote:
> > > > From: Thomas Monjalon <thomas at monjalon.net>
> > > > > 07/08/2017 14:04, Jerin Jacob:
> > > > > > baremetal execution environments may have a different
> > > > > > method to enable RTE_INIT instead of using compiler
> > > > > > constructor scheme. Move RTE_INIT* definition under
> > > > > > exec-env to support different execution environments.
> > > > > >
> > > > > > Signed-off-by: Jerin Jacob <jerin.jacob at
> > > > > > caviumnetworks.com>
> > > > > > ---
> > > > > > app/test-eventdev/evt_test.h | 2 +-
> > > > > > lib/librte_eal/bsdapp/eal/Makefile | 2 +-
> > > > > > .../bsdapp/eal/include/exec-env/rte_eal.h | 51
> > > > > > ++++++++++++++++++++++
> > > > > > lib/librte_eal/common/eal_common_log.c | 2 +
> > > > > > lib/librte_eal/common/include/rte_bus.h | 2 +
> > > > > > lib/librte_eal/common/include/rte_eal.h | 6 ---
> > > > > > lib/librte_eal/common/include/rte_tailq.h | 2 +
> > > > > > lib/librte_eal/linuxapp/eal/Makefile | 2 +-
> > > > > > .../linuxapp/eal/include/exec-env/rte_eal.h | 51
> > > > > > ++++++++++++++++++++++
> > > > > > 9 files changed, 111 insertions(+), 9 deletions(-)
> > > > > > create mode 100644 lib/librte_eal/bsdapp/eal/include/exec-
> > > > > > env/rte_eal.h
> > > > > > create mode 100644 lib/librte_eal/linuxapp/eal/include/exec-
> > > > > > env/rte_eal.h
> > > > >
> > > > > I am not a big fan of duplicating code for Linux and BSD.
> > > > >
> > > > > Maybe we should have different splits and include a common file
> > > > > in Linux and BSD?
> > > >
> > > > OK. This is doable.
> > > >
> > > > > I feel it would be easier to think about the split when adding
> > > > > a new environment.
> > > > > It is also an open question whether we want to support (again)
> > > > > some
> > > > > bare metal environments.
> > > >
> > > > IMO, A factor could be, how much we are OK to change?
> > > >
> > > > Our internal prototype implementation for a bare metal
> > > > environment
> > > > shows things are already in place and may need minor changes like
> > > > this to
> > > > accommodate a bare metal execution environment(accounting the
> > > > latest
> > > > changes of moving pci to driver/pci/..)
> > > >
> > > > If no one care about need for such abstraction then we could drop
> > > > this
> > > > patch. We can always keep local copy of such patches in our
> > > > internal
> > > > tree. I thought to upstream it as it may be useful for someone
> > > > else and
> > > > it is easy for us maintain if changes are in
> > > > lib/librte_eal/<new environment>/eal/ and drivers/*/
> > > Hi Jerin, Thomas,
> > >
> > > This is an old patch, the abstraction seems good idea but it comes
> > > with a
> > > duplication.
> > >
> > > Is there an intention to continue the work? Are we waiting for any
> > > decision?
> > > Any objection to mark it as rejected?
> >
> > I am not sure there is a real desire to make DPDK
> > ready for bare-metal (back again).
> > If any of you are aware of a real use-case, we can re-consider.
>
> Some of the usecases:
>
> # PCIe endpoint mode aka Smart NIC(Where DPDK runs on PCIe card), May
> not need to waste one core for Linux. Specially Smart NIC market has
> less number of cores.
> On the endpoint side, It treats as FW so customer may not have access
> to so nobdoy cares it is Linux or baremetal so may need to waste one
> core for Linux
>
> # VM case, it possible to have bare metal guest just to save one a
> logical core for Linux
>
> # Some of the RTOS like Zephyr already provide TCP/IP stack and good
> subsystems for specific usecases.
>
> # We are using DPDK for pre silicon validation for SoC mode. Bringing
> up linux on emulator takes ages, Baremetal can be used for Harware
> verification too.
>
>
> IMO, As long as it not limiting the a feature of Linux app, Why not to
> allow baremetal? I agree with code duplication. I think, it can be
> fixed easily, Other than that, Is there any concern?
The concern is about the effort required.
Which libc to use? Which dependency is acceptable?
On Tue, 2019-03-12 at 21:33 +0100, Thomas Monjalon wrote:
> 12/03/2019 20:25, Jerin Jacob Kollanukkaran:
> > On Fri, 2019-03-01 at 18:28 +0100, Thomas Monjalon wrote:
> > > External Email
> > >
> > > ---------------------------------------------------------------
> > > ----
> > > ---
> > > 01/03/2019 18:05, Ferruh Yigit:
> > > > On 10/11/2017 3:33 PM, jerin.jacob at caviumnetworks.com (Jerin
> > > > Jacob) wrote:
> > > > > From: Thomas Monjalon <thomas at monjalon.net>
> > > > > > 07/08/2017 14:04, Jerin Jacob:
> > > > > > > baremetal execution environments may have a different
> > > > > > > method to enable RTE_INIT instead of using compiler
> > > > > > > constructor scheme. Move RTE_INIT* definition under
> > > > > > > exec-env to support different execution environments.
> > > > > > >
> > > > > > > Signed-off-by: Jerin Jacob <jerin.jacob at
> > > > > > > caviumnetworks.com>
> > > > > > > ---
> > > > > > >
> > >
> > > I am not sure there is a real desire to make DPDK
> > > ready for bare-metal (back again).
> > > If any of you are aware of a real use-case, we can re-consider.
> >
> > Some of the usecases:
> >
> > # PCIe endpoint mode aka Smart NIC(Where DPDK runs on PCIe card),
> > May
> > not need to waste one core for Linux. Specially Smart NIC market
> > has
> > less number of cores.
> > On the endpoint side, It treats as FW so customer may not have
> > access
> > to so nobdoy cares it is Linux or baremetal so may need to waste
> > one
> > core for Linux
> >
> > # VM case, it possible to have bare metal guest just to save one a
> > logical core for Linux
> >
> > # Some of the RTOS like Zephyr already provide TCP/IP stack and
> > good
> > subsystems for specific usecases.
> >
> > # We are using DPDK for pre silicon validation for SoC mode.
> > Bringing
> > up linux on emulator takes ages, Baremetal can be used for Harware
> > verification too.
> >
> >
> > IMO, As long as it not limiting the a feature of Linux app, Why not
> > to
> > allow baremetal? I agree with code duplication. I think, it can be
> > fixed easily, Other than that, Is there any concern?
>
> The concern is about the effort required.
> Which libc to use? Which dependency is acceptable?
# It should be like FreeBSD or Windows EAL port(Where changes should be
in lib/librte_eal/xxxxxx/)
# Baremetal libc can be newlibc or musl.
# IMO, If bare metal code is open source then the dependency does not
matter
# if RTOS supports POSIX wrappers, the common code changes will be very
minimal.
# In house, We have baremetal support as PoC, where 95% of changes are
in lib/librte_eal/xxxxxx/ with POSIX wrappers.
>
>
13/03/2019 09:02, Jerin Jacob Kollanukkaran:
> On Tue, 2019-03-12 at 21:33 +0100, Thomas Monjalon wrote:
> > 12/03/2019 20:25, Jerin Jacob Kollanukkaran:
> > > On Fri, 2019-03-01 at 18:28 +0100, Thomas Monjalon wrote:
> > > > 01/03/2019 18:05, Ferruh Yigit:
> > > > > On 10/11/2017 3:33 PM, jerin.jacob at caviumnetworks.com (Jerin
> > > > > Jacob) wrote:
> > > > > > From: Thomas Monjalon <thomas at monjalon.net>
> > > > > > > 07/08/2017 14:04, Jerin Jacob:
> > > > > > > > baremetal execution environments may have a different
> > > > > > > > method to enable RTE_INIT instead of using compiler
> > > > > > > > constructor scheme. Move RTE_INIT* definition under
> > > > > > > > exec-env to support different execution environments.
> > > > > > > >
> > > > > > > > Signed-off-by: Jerin Jacob <jerin.jacob at
> > > > > > > > caviumnetworks.com>
> > > > > > > > ---
> > > > > > > >
> > > >
> > > > I am not sure there is a real desire to make DPDK
> > > > ready for bare-metal (back again).
> > > > If any of you are aware of a real use-case, we can re-consider.
> > >
> > > Some of the usecases:
> > >
> > > # PCIe endpoint mode aka Smart NIC(Where DPDK runs on PCIe card),
> > > May
> > > not need to waste one core for Linux. Specially Smart NIC market
> > > has
> > > less number of cores.
> > > On the endpoint side, It treats as FW so customer may not have
> > > access
> > > to so nobdoy cares it is Linux or baremetal so may need to waste
> > > one
> > > core for Linux
> > >
> > > # VM case, it possible to have bare metal guest just to save one a
> > > logical core for Linux
> > >
> > > # Some of the RTOS like Zephyr already provide TCP/IP stack and
> > > good
> > > subsystems for specific usecases.
> > >
> > > # We are using DPDK for pre silicon validation for SoC mode.
> > > Bringing
> > > up linux on emulator takes ages, Baremetal can be used for Harware
> > > verification too.
> > >
> > >
> > > IMO, As long as it not limiting the a feature of Linux app, Why not
> > > to
> > > allow baremetal? I agree with code duplication. I think, it can be
> > > fixed easily, Other than that, Is there any concern?
> >
> > The concern is about the effort required.
> > Which libc to use? Which dependency is acceptable?
>
> # It should be like FreeBSD or Windows EAL port(Where changes should be
> in lib/librte_eal/xxxxxx/)
> # Baremetal libc can be newlibc or musl.
> # IMO, If bare metal code is open source then the dependency does not
> matter
> # if RTOS supports POSIX wrappers, the common code changes will be very
> minimal.
> # In house, We have baremetal support as PoC, where 95% of changes are
> in lib/librte_eal/xxxxxx/ with POSIX wrappers.
Then maybe you should send your patches so we can decide if it is
maintainable enough or not.
On Wed, 2019-03-13 at 09:16 +0100, Thomas Monjalon wrote:
> 13/03/2019 09:02, Jerin Jacob Kollanukkaran:
> > On Tue, 2019-03-12 at 21:33 +0100, Thomas Monjalon wrote:
> > > 12/03/2019 20:25, Jerin Jacob Kollanukkaran:
> > > > On Fri, 2019-03-01 at 18:28 +0100, Thomas Monjalon wrote:
> > > > > 01/03/2019 18:05, Ferruh Yigit:
> > > > > > On 10/11/2017 3:33 PM, jerin.jacob at caviumnetworks.com
> > > > > > (Jerin
> > > > > > Jacob) wrote:
> > > > > > > From: Thomas Monjalon <thomas at monjalon.net>
> > > > > > > > 07/08/2017 14:04, Jerin Jacob:
> > > > > > > > > baremetal execution environments may have a different
> > > > > > > > > method to enable RTE_INIT instead of using compiler
> > > > > > > > > constructor scheme. Move RTE_INIT* definition under
> > > > > > > > > exec-env to support different execution environments.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Jerin Jacob <jerin.jacob at
> > > > > > > > > caviumnetworks.com>
> > > > > > > > > ---
> > > > > > > > >
> > > > >
> > > > > I am not sure there is a real desire to make DPDK
> > > > > ready for bare-metal (back again).
> > > > > If any of you are aware of a real use-case, we can re-
> > > > > consider.
> > > >
> > > > Some of the usecases:
> > > >
> > > > # PCIe endpoint mode aka Smart NIC(Where DPDK runs on PCIe
> > > > card),
> > > > May
> > > > not need to waste one core for Linux. Specially Smart NIC
> > > > market
> > > > has
> > > > less number of cores.
> > > > On the endpoint side, It treats as FW so customer may not have
> > > > access
> > > > to so nobdoy cares it is Linux or baremetal so may need to
> > > > waste
> > > > one
> > > > core for Linux
> > > >
> > > > # VM case, it possible to have bare metal guest just to save
> > > > one a
> > > > logical core for Linux
> > > >
> > > > # Some of the RTOS like Zephyr already provide TCP/IP stack and
> > > > good
> > > > subsystems for specific usecases.
> > > >
> > > > # We are using DPDK for pre silicon validation for SoC mode.
> > > > Bringing
> > > > up linux on emulator takes ages, Baremetal can be used for
> > > > Harware
> > > > verification too.
> > > >
> > > >
> > > > IMO, As long as it not limiting the a feature of Linux app, Why
> > > > not
> > > > to
> > > > allow baremetal? I agree with code duplication. I think, it can
> > > > be
> > > > fixed easily, Other than that, Is there any concern?
> > >
> > > The concern is about the effort required.
> > > Which libc to use? Which dependency is acceptable?
> >
> > # It should be like FreeBSD or Windows EAL port(Where changes
> > should be
> > in lib/librte_eal/xxxxxx/)
> > # Baremetal libc can be newlibc or musl.
> > # IMO, If bare metal code is open source then the dependency does
> > not
> > matter
> > # if RTOS supports POSIX wrappers, the common code changes will be
> > very
> > minimal.
> > # In house, We have baremetal support as PoC, where 95% of changes
> > are
> > in lib/librte_eal/xxxxxx/ with POSIX wrappers.
>
> Then maybe you should send your patches so we can decide if it is
> maintainable enough or not.
The __attribute__((constructor)) only stuff we have issue to support.
The common code changes are related to adapt
__attribute__((constructor)) scheme.
This patch will fix that issue. Other than that there is no common code
changes.i.e everything emulated under lib/librte_eal/new_port/
>
>
On Wed, 2019-03-13 at 14:14 +0530, Jerin Jacob wrote:
> On Wed, 2019-03-13 at 09:16 +0100, Thomas Monjalon wrote:
> > 13/03/2019 09:02, Jerin Jacob Kollanukkaran:
> > > On Tue, 2019-03-12 at 21:33 +0100, Thomas Monjalon wrote:
> > > > 12/03/2019 20:25, Jerin Jacob Kollanukkaran:
> > > > > On Fri, 2019-03-01 at 18:28 +0100, Thomas Monjalon wrote:
> > > > > > 01/03/2019 18:05, Ferruh Yigit:
> > > > > > > On 10/11/2017 3:33 PM, jerin.jacob at caviumnetworks.com
> > > > > > > (Jerin
> > > > > > > Jacob) wrote:
> > > > > > > > From: Thomas Monjalon <thomas at monjalon.net>
> > > > > > > > > 07/08/2017 14:04, Jerin Jacob:
> > > > > > > > > > baremetal execution environments may have a
> > > > > > > > > > different
> > > > > > > > > > method to enable RTE_INIT instead of using compiler
> > > > > > > > > > constructor scheme. Move RTE_INIT* definition under
> > > > > > > > > > exec-env to support different execution
> > > > > > > > > > environments.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Jerin Jacob <jerin.jacob at
> > > > > > > > > > caviumnetworks.com>
> > > > > > > > > > ---
> > > > > > > > > >
> > > > > >
> > > > > > I am not sure there is a real desire to make DPDK
> > > > > > ready for bare-metal (back again).
> > > > > > If any of you are aware of a real use-case, we can re-
> > > > > > consider.
> > > > >
> > > > > Some of the usecases:
> > > > >
> > > > > # PCIe endpoint mode aka Smart NIC(Where DPDK runs on PCIe
> > > > > card),
> > > > > May
> > > > > not need to waste one core for Linux. Specially Smart NIC
> > > > > market
> > > > > has
> > > > > less number of cores.
> > > > > On the endpoint side, It treats as FW so customer may not
> > > > > have
> > > > > access
> > > > > to so nobdoy cares it is Linux or baremetal so may need to
> > > > > waste
> > > > > one
> > > > > core for Linux
> > > > >
> > > > > # VM case, it possible to have bare metal guest just to save
> > > > > one a
> > > > > logical core for Linux
> > > > >
> > > > > # Some of the RTOS like Zephyr already provide TCP/IP stack
> > > > > and
> > > > > good
> > > > > subsystems for specific usecases.
> > > > >
> > > > > # We are using DPDK for pre silicon validation for SoC mode.
> > > > > Bringing
> > > > > up linux on emulator takes ages, Baremetal can be used for
> > > > > Harware
> > > > > verification too.
> > > > >
> > > > >
> > > > > IMO, As long as it not limiting the a feature of Linux app,
> > > > > Why
> > > > > not
> > > > > to
> > > > > allow baremetal? I agree with code duplication. I think, it
> > > > > can
> > > > > be
> > > > > fixed easily, Other than that, Is there any concern?
> > > >
> > > > The concern is about the effort required.
> > > > Which libc to use? Which dependency is acceptable?
> > >
> > > # It should be like FreeBSD or Windows EAL port(Where changes
> > > should be
> > > in lib/librte_eal/xxxxxx/)
> > > # Baremetal libc can be newlibc or musl.
> > > # IMO, If bare metal code is open source then the dependency does
> > > not
> > > matter
> > > # if RTOS supports POSIX wrappers, the common code changes will
> > > be
> > > very
> > > minimal.
> > > # In house, We have baremetal support as PoC, where 95% of
> > > changes
> > > are
> > > in lib/librte_eal/xxxxxx/ with POSIX wrappers.
> >
> > Then maybe you should send your patches so we can decide if it is
> > maintainable enough or not.
>
> The __attribute__((constructor)) only stuff we have issue to
> support.
> The common code changes are related to adapt
> __attribute__((constructor)) scheme.
>
> This patch will fix that issue. Other than that there is no common
> code
> changes.i.e everything emulated under lib/librte_eal/new_port/
Thomas,
I explained the use case and changes required. Let me know, do you need
any other change on this patch to get this patch accepted?
>
>
>
> >
On Thu, 2019-03-14 at 20:44 +0000, Jerin Jacob Kollanukkaran wrote:
> On Wed, 2019-03-13 at 14:14 +0530, Jerin Jacob wrote:
> > On Wed, 2019-03-13 at 09:16 +0100, Thomas Monjalon wrote:
> > > 13/03/2019 09:02, Jerin Jacob Kollanukkaran:
> > > > On Tue, 2019-03-12 at 21:33 +0100, Thomas Monjalon wrote:
> > > > > 12/03/2019 20:25, Jerin Jacob Kollanukkaran:
> > > > > > On Fri, 2019-03-01 at 18:28 +0100, Thomas Monjalon wrote:
> > > > > > > 01/03/2019 18:05, Ferruh Yigit:
> > > > > > > > On 10/11/2017 3:33 PM, jerin.jacob at
> > > > > > > > caviumnetworks.com
> > > > > > > > (Jerin
> > > > > > > > Jacob) wrote:
> > > > > > > > > From: Thomas Monjalon <thomas at monjalon.net>
> > > > > > > > > > 07/08/2017 14:04, Jerin Jacob:
> > > > > > > > > > > baremetal execution environments may have a
> > > > > > > > > > > different
> > > > > > > > > > > method to enable RTE_INIT instead of using
> > > > > > > > > > > compiler
> > > > > > > > > > > constructor scheme. Move RTE_INIT* definition
> > > > > > > > > > > under
> > > > > > > > > > > exec-env to support different execution
> > > > > > > > > > > environments.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Jerin Jacob <jerin.jacob at
> > > > > > > > > > > caviumnetworks.com>
> > > > > > > > > > > ---
> > > > > > > > > > >
> > > > > > >
> > > > > > > I am not sure there is a real desire to make DPDK
> > > > > > > ready for bare-metal (back again).
> > > > > > > If any of you are aware of a real use-case, we can re-
> > > > > > > consider.
> > > > > >
> > > > > > Some of the usecases:
> > > > > >
> > > > > > # PCIe endpoint mode aka Smart NIC(Where DPDK runs on PCIe
> > > > > > card),
> > > > > > May
> > > > > > not need to waste one core for Linux. Specially Smart NIC
> > > > > > market
> > > > > > has
> > > > > > less number of cores.
> > > > > > On the endpoint side, It treats as FW so customer may not
> > > > > > have
> > > > > > access
> > > > > > to so nobdoy cares it is Linux or baremetal so may need to
> > > > > > waste
> > > > > > one
> > > > > > core for Linux
> > > > > >
> > > > > > # VM case, it possible to have bare metal guest just to
> > > > > > save
> > > > > > one a
> > > > > > logical core for Linux
> > > > > >
> > > > > > # Some of the RTOS like Zephyr already provide TCP/IP stack
> > > > > > and
> > > > > > good
> > > > > > subsystems for specific usecases.
> > > > > >
> > > > > > # We are using DPDK for pre silicon validation for SoC
> > > > > > mode.
> > > > > > Bringing
> > > > > > up linux on emulator takes ages, Baremetal can be used for
> > > > > > Harware
> > > > > > verification too.
> > > > > >
> > > > > >
> > > > > > IMO, As long as it not limiting the a feature of Linux app,
> > > > > > Why
> > > > > > not
> > > > > > to
> > > > > > allow baremetal? I agree with code duplication. I think, it
> > > > > > can
> > > > > > be
> > > > > > fixed easily, Other than that, Is there any concern?
> > > > >
> > > > > The concern is about the effort required.
> > > > > Which libc to use? Which dependency is acceptable?
> > > >
> > > > # It should be like FreeBSD or Windows EAL port(Where changes
> > > > should be
> > > > in lib/librte_eal/xxxxxx/)
> > > > # Baremetal libc can be newlibc or musl.
> > > > # IMO, If bare metal code is open source then the dependency
> > > > does
> > > > not
> > > > matter
> > > > # if RTOS supports POSIX wrappers, the common code changes will
> > > > be
> > > > very
> > > > minimal.
> > > > # In house, We have baremetal support as PoC, where 95% of
> > > > changes
> > > > are
> > > > in lib/librte_eal/xxxxxx/ with POSIX wrappers.
> > >
> > > Then maybe you should send your patches so we can decide if it is
> > > maintainable enough or not.
> >
> > The __attribute__((constructor)) only stuff we have issue to
> > support.
> > The common code changes are related to adapt
> > __attribute__((constructor)) scheme.
> >
> > This patch will fix that issue. Other than that there is no common
> > code
> > changes.i.e everything emulated under lib/librte_eal/new_port/
>
> Thomas,
>
> I explained the use case and changes required. Let me know, do you
> need
> any other change on this patch to get this patch accepted?
Ping?
>
>
>
> >
> >
02/04/2019 03:15, Jerin Jacob Kollanukkaran:
> On Thu, 2019-03-14 at 20:44 +0000, Jerin Jacob Kollanukkaran wrote:
> > On Wed, 2019-03-13 at 14:14 +0530, Jerin Jacob wrote:
> > > On Wed, 2019-03-13 at 09:16 +0100, Thomas Monjalon wrote:
> > > > Then maybe you should send your patches so we can decide if it is
> > > > maintainable enough or not.
> > >
> > > The __attribute__((constructor)) only stuff we have issue to
> > > support.
> > > The common code changes are related to adapt
> > > __attribute__((constructor)) scheme.
> > >
> > > This patch will fix that issue. Other than that there is no common
> > > code
> > > changes.i.e everything emulated under lib/librte_eal/new_port/
> >
> > Thomas,
> >
> > I explained the use case and changes required. Let me know, do you
> > need
> > any other change on this patch to get this patch accepted?
>
> Ping?
This patch needs to be refreshed.
And I have some comments, sending in another email with better context.
11/10/2017 16:33, Jerin Jacob:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 07/08/2017 14:04, Jerin Jacob:
> > > baremetal execution environments may have a different
> > > method to enable RTE_INIT instead of using compiler
> > > constructor scheme. Move RTE_INIT* definition under
> > > exec-env to support different execution environments.
> > >
> > > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > > ---
> > > app/test-eventdev/evt_test.h | 2 +-
> > > lib/librte_eal/bsdapp/eal/Makefile | 2 +-
> > > .../bsdapp/eal/include/exec-env/rte_eal.h | 51 ++++++++++++++++++++++
I sent a patch to flatten the hierarchy, removing exec-env.
And I'm not sure about the file name rte_eal.h.
Please could you move it to lib/librte_eal/<os>/eal/include/rte_exec_env.h
or another better name? Note that Windows is introducing rte_os.h.
PS: I'm not sure about the intent of rte_os.h. Should it be rte_libc.h?
> > > lib/librte_eal/common/eal_common_log.c | 2 +
> > > lib/librte_eal/common/include/rte_bus.h | 2 +
> > > lib/librte_eal/common/include/rte_eal.h | 6 ---
> > > lib/librte_eal/common/include/rte_tailq.h | 2 +
> > > lib/librte_eal/linuxapp/eal/Makefile | 2 +-
> > > .../linuxapp/eal/include/exec-env/rte_eal.h | 51 ++++++++++++++++++++++
> >
> > I am not a big fan of duplicating code for Linux and BSD.
> >
> > Maybe we should have different splits and include a common file
> > in Linux and BSD?
>
> OK. This is doable.
After some thoughts about Windows port, I think we need to consider
a better split.
The constructors are the same for Linux, BSD and Windows, isn't it?
Is it related to splitting between POSIX libc and others?
> On Apr 2, 2019, at 7:57 AM, Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 11/10/2017 16:33, Jerin Jacob:
>> From: Thomas Monjalon <thomas@monjalon.net>
>>> 07/08/2017 14:04, Jerin Jacob:
>>>> baremetal execution environments may have a different
>>>> method to enable RTE_INIT instead of using compiler
>>>> constructor scheme. Move RTE_INIT* definition under
>>>> exec-env to support different execution environments.
>>>>
>>>> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
>>>> ---
>>>> app/test-eventdev/evt_test.h | 2 +-
>>>> lib/librte_eal/bsdapp/eal/Makefile | 2 +-
>>>> .../bsdapp/eal/include/exec-env/rte_eal.h | 51 ++++++++++++++++++++++
>
> I sent a patch to flatten the hierarchy, removing exec-env.
> And I'm not sure about the file name rte_eal.h.
> Please could you move it to lib/librte_eal/<os>/eal/include/rte_exec_env.h
> or another better name? Note that Windows is introducing rte_os.h.
> PS: I'm not sure about the intent of rte_os.h. Should it be rte_libc.h?
I agree here unless the rte_os.h or (rte_libc.h) is really a header to just include rte_windows_libc.h, rte_linux_libc.h or rte_<OS>_libc.h to simplify including OS specific headers and differences in libc designs.
>
>>>> lib/librte_eal/common/eal_common_log.c | 2 +
>>>> lib/librte_eal/common/include/rte_bus.h | 2 +
>>>> lib/librte_eal/common/include/rte_eal.h | 6 ---
>>>> lib/librte_eal/common/include/rte_tailq.h | 2 +
>>>> lib/librte_eal/linuxapp/eal/Makefile | 2 +-
>>>> .../linuxapp/eal/include/exec-env/rte_eal.h | 51 ++++++++++++++++++++++
>>>
>>> I am not a big fan of duplicating code for Linux and BSD.
>>>
>>> Maybe we should have different splits and include a common file
>>> in Linux and BSD?
>>
>> OK. This is doable.
>
> After some thoughts about Windows port, I think we need to consider
> a better split.
> The constructors are the same for Linux, BSD and Windows, isn't it?
> Is it related to splitting between POSIX libc and others?
>
>
>
Regards,
Keith
@@ -37,7 +37,7 @@
#include <stdbool.h>
#include <sys/queue.h>
-#include <rte_eal.h>
+#include <exec-env/rte_eal.h>
enum evt_test_result {
EVT_TEST_SUCCESS,
@@ -107,7 +107,7 @@ CFLAGS_eal_thread.o += -Wno-return-type
CFLAGS_eal_hpet.o += -Wno-return-type
endif
-INC := rte_interrupts.h
+INC := rte_interrupts.h rte_eal.h
SYMLINK-$(CONFIG_RTE_EXEC_ENV_BSDAPP)-include/exec-env := \
$(addprefix include/exec-env/,$(INC))
new file mode 100644
@@ -0,0 +1,51 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-2017 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _BSDAPP_RTE_EAL_H_
+#define _BSDAPP_RTE_EAL_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#define RTE_INIT(func) \
+static void __attribute__((constructor, used)) func(void)
+
+#define RTE_INIT_PRIO(func, prio) \
+static void __attribute__((constructor(prio), used)) func(void)
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _BSDAPP_RTE_EAL_H_ */
@@ -43,6 +43,8 @@
#include <rte_log.h>
#include <rte_per_lcore.h>
+#include <exec-env/rte_eal.h>
+
#include "eal_private.h"
/* global log structure */
@@ -52,6 +52,8 @@ extern "C" {
#include <rte_log.h>
#include <rte_dev.h>
+#include <exec-env/rte_eal.h>
+
/** Double linked list of buses */
TAILQ_HEAD(rte_bus_list, rte_bus);
@@ -287,12 +287,6 @@ static inline int rte_gettid(void)
return RTE_PER_LCORE(_thread_id);
}
-#define RTE_INIT(func) \
-static void __attribute__((constructor, used)) func(void)
-
-#define RTE_INIT_PRIO(func, prio) \
-static void __attribute__((constructor(prio), used)) func(void)
-
#ifdef __cplusplus
}
#endif
@@ -48,6 +48,8 @@ extern "C" {
#include <stdio.h>
#include <rte_debug.h>
+#include <exec-env/rte_eal.h>
+
/** dummy structure type used by the rte_tailq APIs */
struct rte_tailq_entry {
TAILQ_ENTRY(rte_tailq_entry) next; /**< Pointer entries for a tailq list */
@@ -130,7 +130,7 @@ ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y)
CFLAGS_eal_thread.o += -Wno-return-type
endif
-INC := rte_interrupts.h rte_kni_common.h rte_dom0_common.h
+INC := rte_interrupts.h rte_kni_common.h rte_dom0_common.h rte_eal.h
SYMLINK-$(CONFIG_RTE_EXEC_ENV_LINUXAPP)-include/exec-env := \
$(addprefix include/exec-env/,$(INC))
new file mode 100644
@@ -0,0 +1,51 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-2017 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _LINUXAPP_RTE_EAL_H_
+#define _LINUXAPP_RTE_EAL_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#define RTE_INIT(func) \
+static void __attribute__((constructor, used)) func(void)
+
+#define RTE_INIT_PRIO(func, prio) \
+static void __attribute__((constructor(prio), used)) func(void)
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _LINUXAPP_RTE_EAL_H_ */