From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org, bruce.richardson@intel.com
Subject: Re: [dpdk-dev] [PATCH] eal: change init macro as exec environment specific
Date: Wed, 11 Oct 2017 20:03:54 +0530 [thread overview]
Message-ID: <20171011143352.GA23500@jerin> (raw)
In-Reply-To: <30782747.pV0nTTKWH9@xps>
-----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/*/
next prev parent reply other threads:[~2017-10-11 14:34 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-07 12:04 Jerin Jacob
2017-10-11 13:02 ` Thomas Monjalon
2017-10-11 14:33 ` Jerin Jacob [this message]
2019-03-01 17:05 ` Ferruh Yigit
2019-03-01 17:16 ` Ferruh Yigit
2019-03-01 17:28 ` Thomas Monjalon
2019-03-12 19:25 ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2019-03-12 20:33 ` Thomas Monjalon
2019-03-13 8:02 ` Jerin Jacob Kollanukkaran
2019-03-13 8:16 ` Thomas Monjalon
2019-03-13 8:44 ` Jerin Jacob Kollanukkaran
2019-03-14 20:44 ` Jerin Jacob Kollanukkaran
2019-03-14 20:44 ` Jerin Jacob Kollanukkaran
2019-04-02 1:15 ` Jerin Jacob Kollanukkaran
2019-04-02 1:15 ` Jerin Jacob Kollanukkaran
2019-04-02 12:45 ` Thomas Monjalon
2019-04-02 12:45 ` Thomas Monjalon
2019-04-02 12:57 ` [dpdk-dev] " Thomas Monjalon
2019-04-02 12:57 ` Thomas Monjalon
2019-04-02 13:20 ` Wiles, Keith
2019-04-02 13:20 ` Wiles, Keith
2019-04-03 19:28 ` [dpdk-dev] [PATCH v2] " Jerin Jacob Kollanukkaran
2019-04-03 19:28 ` Jerin Jacob Kollanukkaran
2019-04-03 20:07 ` Thomas Monjalon
2019-04-03 20:07 ` Thomas Monjalon
2019-04-03 21:52 ` Thomas Monjalon
2019-04-03 21:52 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171011143352.GA23500@jerin \
--to=jerin.jacob@caviumnetworks.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).