[dpdk-dev] [PATCH] eal: change init macro as exec environment specific

[dpdk-dev] [PATCH] eal: change init macro as exec environment specific

[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

diff --git a/app/test-eventdev/evt_test.h b/app/test-eventdev/evt_test.h
index 17bdd1650..f63f9a814 100644
--- a/app/test-eventdev/evt_test.h
+++ b/app/test-eventdev/evt_test.h
@@ -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,
diff --git a/lib/librte_eal/bsdapp/eal/Makefile b/lib/librte_eal/bsdapp/eal/Makefile
index 05517a2dc..2f5574f79 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -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))
diff --git a/lib/librte_eal/bsdapp/eal/include/exec-env/rte_eal.h b/lib/librte_eal/bsdapp/eal/include/exec-env/rte_eal.h
new file mode 100644
index 000000000..1f3222f01
--- /dev/null
+++ b/lib/librte_eal/bsdapp/eal/include/exec-env/rte_eal.h
@@ -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_ */
diff --git a/lib/librte_eal/common/eal_common_log.c b/lib/librte_eal/common/eal_common_log.c
index 0e3b93209..236a662b0 100644
--- a/lib/librte_eal/common/eal_common_log.c
+++ b/lib/librte_eal/common/eal_common_log.c
@@ -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 */
diff --git a/lib/librte_eal/common/include/rte_bus.h b/lib/librte_eal/common/include/rte_bus.h
index c79368d3c..52e13bd0d 100644
--- a/lib/librte_eal/common/include/rte_bus.h
+++ b/lib/librte_eal/common/include/rte_bus.h
@@ -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);
 
diff --git a/lib/librte_eal/common/include/rte_eal.h b/lib/librte_eal/common/include/rte_eal.h
index 0e7363d77..cce5160bd 100644
--- a/lib/librte_eal/common/include/rte_eal.h
+++ b/lib/librte_eal/common/include/rte_eal.h
@@ -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
diff --git a/lib/librte_eal/common/include/rte_tailq.h b/lib/librte_eal/common/include/rte_tailq.h
index 3aae098ae..6a5ca3731 100644
--- a/lib/librte_eal/common/include/rte_tailq.h
+++ b/lib/librte_eal/common/include/rte_tailq.h
@@ -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 */
diff --git a/lib/librte_eal/linuxapp/eal/Makefile b/lib/librte_eal/linuxapp/eal/Makefile
index e6ab6c30f..ec8ffddf4 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -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))
diff --git a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_eal.h b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_eal.h
new file mode 100644
index 000000000..bac4924a6
--- /dev/null
+++ b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_eal.h
@@ -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_ */
-- 
2.14.0

Re: [dpdk-dev] [PATCH] eal: change init macro as exec environment specific

[Thomas Monjalon]

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.

Re: [dpdk-dev] [PATCH] eal: change init macro as exec environment specific

[Jerin Jacob]

-----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/*/

Re: [dpdk-dev] [PATCH] eal: change init macro as exec environment specific

[Ferruh Yigit]

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

Re: [dpdk-dev] [PATCH] eal: change init macro as exec environment specific

[Ferruh Yigit]

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
> 

Re: [dpdk-dev] [PATCH] eal: change init macro as exec environment specific

[Thomas Monjalon]

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.

Re: [dpdk-dev] [EXT] Re: [PATCH] eal: change init macro as exec environment specific

[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?

Jerin

Re: [dpdk-dev] [EXT] Re: [PATCH] eal: change init macro as exec environment specific

[Thomas Monjalon]

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?

Re: [dpdk-dev] [EXT] Re: [PATCH] eal: change init macro as exec environment specific

[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:
> > > 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.




> 
> 

Re: [dpdk-dev] [EXT] Re: [PATCH] eal: change init macro as exec environment specific

[Thomas Monjalon]

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.

Re: [dpdk-dev] [EXT] Re: [PATCH] eal: change init macro as exec environment specific

[Jerin Jacob Kollanukkaran]

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/



> 
> 

Re: [dpdk-dev] [EXT] Re: [PATCH] eal: change init macro as exec environment specific

[Jerin Jacob Kollanukkaran]

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?




> 
> 
> 
> > 

Re: [dpdk-dev] [EXT] Re: [PATCH] eal: change init macro as exec environment specific

[Jerin Jacob Kollanukkaran]

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?




> 
> 
> 
> > 

Re: [dpdk-dev] [EXT] Re: [PATCH] eal: change init macro as exec environment specific

[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:
> > > 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?


> 
> 
> 
> > 
> > 

Re: [dpdk-dev] [EXT] Re: [PATCH] eal: change init macro as exec environment specific

[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:
> > > 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?


> 
> 
> 
> > 
> > 

Re: [dpdk-dev] [EXT] Re: [PATCH] eal: change init macro as exec environment specific

[Thomas Monjalon]

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.

Re: [dpdk-dev] [EXT] Re: [PATCH] eal: change init macro as exec environment specific

[Thomas Monjalon]

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.

Re: [dpdk-dev] [PATCH] eal: change init macro as exec environment specific

[Thomas Monjalon]

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?

Re: [dpdk-dev] [PATCH] eal: change init macro as exec environment specific

[Thomas Monjalon]

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?

Re: [dpdk-dev] [PATCH] eal: change init macro as exec environment specific

[Wiles, Keith]

> 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

Re: [dpdk-dev] [PATCH] eal: change init macro as exec environment specific

[Wiles, Keith]

> 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

[dpdk-dev] [PATCH v2] eal: change init macro as exec environment specific

[Jerin Jacob Kollanukkaran]

From: Jerin Jacob <jerinj@marvell.com>

baremetal execution environments may have a different
method to enable RTE_INIT instead of using compiler
constructor and/or OS specific linker scheme.
Allow an option to override RTE_INIT* macros using
rte_os.h or appropriate header file.

Signed-off-by: Jerin Jacob <jerinj@marvell.com>
---

v2:
- Leverage the rte_os.h created by Windows port to override RTE_INIT* macro if needed.
- Removed the exec environment specific librte_eal/<OS>/eal/include/exec-env/rte_exec-env.h
file creation
- Removed the duplication of RTE_INIT_* definition on each rte_exec-env.h file
as it is common for Linux,FreeBSD and Windows port

---
 lib/librte_eal/common/include/rte_common.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/librte_eal/common/include/rte_common.h b/lib/librte_eal/common/include/rte_common.h
index 1d3c33021..f2691b4e1 100644
--- a/lib/librte_eal/common/include/rte_common.h
+++ b/lib/librte_eal/common/include/rte_common.h
@@ -106,8 +106,10 @@ typedef uint16_t unaligned_uint16_t;
  *   Priority number must be above 100.
  *   Lowest number is the first to run.
  */
+#ifndef RTE_INIT_PRIO /* Allow to override from eal */
 #define RTE_INIT_PRIO(func, prio) \
 static void __attribute__((constructor(RTE_PRIO(prio)), used)) func(void)
+#endif
 
 /**
  * Run function before main() with low priority.
@@ -129,8 +131,10 @@ static void __attribute__((constructor(RTE_PRIO(prio)), used)) func(void)
  *   Priority number must be above 100.
  *   Lowest number is the last to run.
  */
+#ifndef RTE_FINI_PRIO /* Allow to override from eal */
 #define RTE_FINI_PRIO(func, prio) \
 static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
+#endif
 
 /**
  * Run after main() with high priority.
-- 
2.21.0

[dpdk-dev] [PATCH v2] eal: change init macro as exec environment specific

[Jerin Jacob Kollanukkaran]

From: Jerin Jacob <jerinj@marvell.com>

baremetal execution environments may have a different
method to enable RTE_INIT instead of using compiler
constructor and/or OS specific linker scheme.
Allow an option to override RTE_INIT* macros using
rte_os.h or appropriate header file.

Signed-off-by: Jerin Jacob <jerinj@marvell.com>
---

v2:
- Leverage the rte_os.h created by Windows port to override RTE_INIT* macro if needed.
- Removed the exec environment specific librte_eal/<OS>/eal/include/exec-env/rte_exec-env.h
file creation
- Removed the duplication of RTE_INIT_* definition on each rte_exec-env.h file
as it is common for Linux,FreeBSD and Windows port

---
 lib/librte_eal/common/include/rte_common.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/librte_eal/common/include/rte_common.h b/lib/librte_eal/common/include/rte_common.h
index 1d3c33021..f2691b4e1 100644
--- a/lib/librte_eal/common/include/rte_common.h
+++ b/lib/librte_eal/common/include/rte_common.h
@@ -106,8 +106,10 @@ typedef uint16_t unaligned_uint16_t;
  *   Priority number must be above 100.
  *   Lowest number is the first to run.
  */
+#ifndef RTE_INIT_PRIO /* Allow to override from eal */
 #define RTE_INIT_PRIO(func, prio) \
 static void __attribute__((constructor(RTE_PRIO(prio)), used)) func(void)
+#endif
 
 /**
  * Run function before main() with low priority.
@@ -129,8 +131,10 @@ static void __attribute__((constructor(RTE_PRIO(prio)), used)) func(void)
  *   Priority number must be above 100.
  *   Lowest number is the last to run.
  */
+#ifndef RTE_FINI_PRIO /* Allow to override from eal */
 #define RTE_FINI_PRIO(func, prio) \
 static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
+#endif
 
 /**
  * Run after main() with high priority.
-- 
2.21.0

Re: [dpdk-dev] [PATCH v2] eal: change init macro as exec environment specific

[Thomas Monjalon]

03/04/2019 21:28, Jerin Jacob Kollanukkaran:
> From: Jerin Jacob <jerinj@marvell.com>
> 
> baremetal execution environments may have a different
> method to enable RTE_INIT instead of using compiler
> constructor and/or OS specific linker scheme.
> Allow an option to override RTE_INIT* macros using
> rte_os.h or appropriate header file.
> 
> Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> ---
> 
> v2:
> - Leverage the rte_os.h created by Windows port to override RTE_INIT* macro if needed.
> - Removed the exec environment specific librte_eal/<OS>/eal/include/exec-env/rte_exec-env.h
> file creation
> - Removed the duplication of RTE_INIT_* definition on each rte_exec-env.h file
> as it is common for Linux,FreeBSD and Windows port
> 
> --- a/lib/librte_eal/common/include/rte_common.h
> +++ b/lib/librte_eal/common/include/rte_common.h
> @@ -106,8 +106,10 @@ typedef uint16_t unaligned_uint16_t;
>   *   Priority number must be above 100.
>   *   Lowest number is the first to run.
>   */
> +#ifndef RTE_INIT_PRIO /* Allow to override from eal */
>  #define RTE_INIT_PRIO(func, prio) \
>  static void __attribute__((constructor(RTE_PRIO(prio)), used)) func(void)
> +#endif

I did not think about such #ifndef, it's a lot simpler :)

As a nit, I would just fix eal to uppercase EAL in the above comment.
I may do it on apply.

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

Re: [dpdk-dev] [PATCH v2] eal: change init macro as exec environment specific

[Thomas Monjalon]

03/04/2019 21:28, Jerin Jacob Kollanukkaran:
> From: Jerin Jacob <jerinj@marvell.com>
> 
> baremetal execution environments may have a different
> method to enable RTE_INIT instead of using compiler
> constructor and/or OS specific linker scheme.
> Allow an option to override RTE_INIT* macros using
> rte_os.h or appropriate header file.
> 
> Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> ---
> 
> v2:
> - Leverage the rte_os.h created by Windows port to override RTE_INIT* macro if needed.
> - Removed the exec environment specific librte_eal/<OS>/eal/include/exec-env/rte_exec-env.h
> file creation
> - Removed the duplication of RTE_INIT_* definition on each rte_exec-env.h file
> as it is common for Linux,FreeBSD and Windows port
> 
> --- a/lib/librte_eal/common/include/rte_common.h
> +++ b/lib/librte_eal/common/include/rte_common.h
> @@ -106,8 +106,10 @@ typedef uint16_t unaligned_uint16_t;
>   *   Priority number must be above 100.
>   *   Lowest number is the first to run.
>   */
> +#ifndef RTE_INIT_PRIO /* Allow to override from eal */
>  #define RTE_INIT_PRIO(func, prio) \
>  static void __attribute__((constructor(RTE_PRIO(prio)), used)) func(void)
> +#endif

I did not think about such #ifndef, it's a lot simpler :)

As a nit, I would just fix eal to uppercase EAL in the above comment.
I may do it on apply.

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

Re: [dpdk-dev] [PATCH v2] eal: change init macro as exec environment specific

[Thomas Monjalon]

03/04/2019 22:07, Thomas Monjalon:
> 03/04/2019 21:28, Jerin Jacob Kollanukkaran:
> > From: Jerin Jacob <jerinj@marvell.com>
> > 
> > baremetal execution environments may have a different
> > method to enable RTE_INIT instead of using compiler
> > constructor and/or OS specific linker scheme.
> > Allow an option to override RTE_INIT* macros using
> > rte_os.h or appropriate header file.
> > 
> > Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> 
> Acked-by: Thomas Monjalon <thomas@monjalon.net>

Applied, thanks

Re: [dpdk-dev] [PATCH v2] eal: change init macro as exec environment specific

[Thomas Monjalon]

03/04/2019 22:07, Thomas Monjalon:
> 03/04/2019 21:28, Jerin Jacob Kollanukkaran:
> > From: Jerin Jacob <jerinj@marvell.com>
> > 
> > baremetal execution environments may have a different
> > method to enable RTE_INIT instead of using compiler
> > constructor and/or OS specific linker scheme.
> > Allow an option to override RTE_INIT* macros using
> > rte_os.h or appropriate header file.
> > 
> > Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> 
> Acked-by: Thomas Monjalon <thomas@monjalon.net>

Applied, thanks