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?
