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

[Jerin Jacob Kollanukkaran <jerinj@marvell.com>]

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