From: Neil Horman <nhorman@tuxdriver.com>
To: Omar Cardona <ocardona@microsoft.com>
Cc: Fady Bader <fady@mellanox.com>, "dev@dpdk.org" <dev@dpdk.org>,
"thomas@monjalon.net" <thomas@monjalon.net>,
"tbashar@mellanox.com" <tbashar@mellanox.com>,
"talshn@mellanox.com" <talshn@mellanox.com>,
"yohadt@mellanox.com" <yohadt@mellanox.com>,
"dmitry.kozliuk@gmail.com" <dmitry.kozliuk@gmail.com>,
Harini Ramakrishnan <Harini.Ramakrishnan@microsoft.com>,
"pallavi.kadam@intel.com" <pallavi.kadam@intel.com>,
"ranjit.menon@intel.com" <ranjit.menon@intel.com>,
"olivier.matz@6wind.com" <olivier.matz@6wind.com>,
"arybchenko@solarflare.com" <arybchenko@solarflare.com>,
"mdr@ashroe.eu" <mdr@ashroe.eu>
Subject: Re: [dpdk-dev] [EXTERNAL] Re: [PATCH v2 1/4] eal: disable function versioning on Windows
Date: Tue, 2 Jun 2020 06:27:22 -0400 [thread overview]
Message-ID: <20200602102722.GA273284@hmswarspite.think-freely.org> (raw)
In-Reply-To: <CY4PR21MB027724067ACCA896F964B37EDA8A0@CY4PR21MB0277.namprd21.prod.outlook.com>
On Mon, Jun 01, 2020 at 09:46:18PM +0000, Omar Cardona wrote:
> >> Do we know if we have future plans of supporting dlls on windows in the future?
> - Hi Neil, yes this is of interest to us (Windows).
> - Specifically to aid in non-disruptive granular servicing/updating.
> - Our primary scenario Userspace VMSwitch is biased towards shared libraries for production servicing
>
Ok, do you have recommendations on how to provide backwards compatibility
between dpdk versions? From what I read the most direct solution would be
per-application dll bundling (which seems to me to defeat the purpose of
creating a dll, but if its the only solution, perhaps thats all we have to work
with). Is there a better solution?
If not, then I would suggest that, instead of disabling shared libraries on
Windows, as we do below, we allow it, and redefine VERSION_SYMBOL[_EXPERIMENTAL]
to do nothing, and implement BIND_DEFAULT_SYMBOL to act like MAP_STATIC_SYMBOL
by aliasing the supplied symbol name to the provided export name. I think msvc
supports aliasing, correct?
Neil
>
> -----Original Message-----
> From: Neil Horman <nhorman@tuxdriver.com>
> Sent: Monday, June 1, 2020 12:56 PM
> To: Fady Bader <fady@mellanox.com>
> Cc: dev@dpdk.org; thomas@monjalon.net; tbashar@mellanox.com; talshn@mellanox.com; yohadt@mellanox.com; dmitry.kozliuk@gmail.com; Harini Ramakrishnan <Harini.Ramakrishnan@microsoft.com>; Omar Cardona <ocardona@microsoft.com>; pallavi.kadam@intel.com; ranjit.menon@intel.com; olivier.matz@6wind.com; arybchenko@solarflare.com; mdr@ashroe.eu
> Subject: [EXTERNAL] Re: [PATCH v2 1/4] eal: disable function versioning on Windows
>
> On Mon, Jun 01, 2020 at 01:31:36PM +0300, Fady Bader wrote:
> > Function versioning is not needed on Windows, also the function
> > versioning implementation is not supported by Windows.
> > Function versioning was disabled on Windows.
> >
> I get that windows doesn't seem to support symbol level versioning, but I'm not sure its reasonable to say that its not needed, unless we never have any intention of building dpdk on windows using a DSO model. The below definately solves the immediate problem, but if we plan to support windows with dynamic library builds, this just kicks the can down the road.
>
> Do we know if we have future plans of supporting dlls on windows in the future?
>
> Neil
>
> > Signed-off-by: Fady Bader <fady@mellanox.com>
> > ---
> > lib/librte_eal/include/rte_function_versioning.h | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/lib/librte_eal/include/rte_function_versioning.h
> > b/lib/librte_eal/include/rte_function_versioning.h
> > index f588f2643..cee06602e 100644
> > --- a/lib/librte_eal/include/rte_function_versioning.h
> > +++ b/lib/librte_eal/include/rte_function_versioning.h
> > @@ -11,6 +11,10 @@
> > #error Use of function versioning disabled, is "use_function_versioning=true" in meson.build?
> > #endif
> >
> > +#ifdef RTE_EXEC_ENV_WINDOWS
> > +#undef RTE_BUILD_SHARED_LIB
> > +#endif
> > +
> > #ifdef RTE_BUILD_SHARED_LIB
> >
> > /*
> > --
> > 2.16.1.windows.4
> >
> >
>
next prev parent reply other threads:[~2020-06-02 10:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-01 10:31 [dpdk-dev] [PATCH v2 0/4] build mempool " Fady Bader
2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 1/4] eal: disable function versioning " Fady Bader
2020-06-01 19:55 ` Neil Horman
2020-06-01 21:46 ` [dpdk-dev] [EXTERNAL] " Omar Cardona
2020-06-02 10:27 ` Neil Horman [this message]
2020-06-02 10:40 ` Thomas Monjalon
2020-06-11 10:09 ` Kinsella, Ray
2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 2/4] mempool: use generic memory management Fady Bader
2020-06-01 19:59 ` Dmitry Kozlyuk
2020-06-01 20:47 ` Ranjit Menon
2020-06-01 21:14 ` Thomas Monjalon
2020-06-02 7:40 ` Andrew Rybchenko
2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 3/4] eal: export needed functions for mempool Fady Bader
2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 4/4] mempool: mempool build on Windows Fady Bader
2020-06-02 7:41 ` Andrew Rybchenko
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=20200602102722.GA273284@hmswarspite.think-freely.org \
--to=nhorman@tuxdriver.com \
--cc=Harini.Ramakrishnan@microsoft.com \
--cc=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
--cc=dmitry.kozliuk@gmail.com \
--cc=fady@mellanox.com \
--cc=mdr@ashroe.eu \
--cc=ocardona@microsoft.com \
--cc=olivier.matz@6wind.com \
--cc=pallavi.kadam@intel.com \
--cc=ranjit.menon@intel.com \
--cc=talshn@mellanox.com \
--cc=tbashar@mellanox.com \
--cc=thomas@monjalon.net \
--cc=yohadt@mellanox.com \
/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).