From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 80715A0C4F; Fri, 16 Jul 2021 11:40:39 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 01CB140151; Fri, 16 Jul 2021 11:40:39 +0200 (CEST) Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) by mails.dpdk.org (Postfix) with ESMTP id 003424014D for ; Fri, 16 Jul 2021 11:40:37 +0200 (CEST) Received: by mail-lj1-f177.google.com with SMTP id bn5so12856863ljb.10 for ; Fri, 16 Jul 2021 02:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=908klsXRE10Wtnb6s4cjLWUJ2oVo4Ra7vJoKnR4hl38=; b=D348oTXKFEaqHNY1w2LBE9sG4JRAKeVcf5107gn6/Xbwq0gMHQZPlzzLK4Pm0tBzxO lH2rHuH5bTPJ/6enw+aiqlSq2PL19J+kFX1ZlpYAyP5PTz236y4+SldIzbmRl1eJztOR LcTpxc24vqtqeb62N/l6lGjLSc2LpkAMmyOSLxNKXc3uXHGQlKUz5rDDYr0G9mDZgoSV OyRTjNRTZu6bRiHa0mjynd2mq3D576KD0MbPkJ0ZgP8Py1RSlZ+OuGaLoP7WhUPe8eUp uYum42bkmZpDwHaRoLT0MHtIKexSCDhhkb4JkP8LypRQoD42lice030weFYXy6T9L1o5 aAZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=908klsXRE10Wtnb6s4cjLWUJ2oVo4Ra7vJoKnR4hl38=; b=MLslCCdrLx73gkQUp8/cokauv/oRLF+AR2vm7nr/tsKAzYbcRrgeM9UxTlitsyUD0v CC7lo7f2cw2Ata8WHwEBWjL/WtFYPUxOQztMweYQim39eVmemdpCCL1W4/Y0tGuIiSck SHtyLZJt29R3BlDwSSEmhW8Zkmw76oCal9ENRydHlc06EFx8Xgb9x7XXBBIa2ShT8PNN m92Bt1sf19LOilirXfs4n6qzwW45yca17HxXGd9ho47N7vQ0tcY33kI9L/s1Yhry9bnl +c2O9Zp6845zvfhd3dycL9Eo0Tpv18/FJpCNRZyoredkfL/cHzXTFDkmsY9fsR3BQyUI s9og== X-Gm-Message-State: AOAM532o4CKNdCHQM3mwk3MorB6Z952w2X442x6RIJdbPBVi3QZSWB4t TjvJuEPSwobxSL4iMUwUl7U= X-Google-Smtp-Source: ABdhPJwdcaM+IMUqIi8vY937z3XFpKMnOANU6AdtDIH3DZGTDXQHuKI0nZ/bId76XdUNDe0Ic9z1CA== X-Received: by 2002:a2e:890b:: with SMTP id d11mr8522869lji.477.1626428437422; Fri, 16 Jul 2021 02:40:37 -0700 (PDT) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id u4sm928708lje.128.2021.07.16.02.40.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Jul 2021 02:40:36 -0700 (PDT) Date: Fri, 16 Jul 2021 12:40:35 +0300 From: Dmitry Kozlyuk To: Tyler Retzlaff Cc: dev@dpdk.org, thomas@monjalon.net Message-ID: <20210716124035.51741861@sovereign> In-Reply-To: <20210709010319.GB23346@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20210708192109.GA13966@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20210708234953.67906871@sovereign> <20210709010319.GB23346@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] RFC enabling dll/dso for dpdk on windows X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2021-07-08 18:03 (UTC-0700), Tyler Retzlaff: > On Thu, Jul 08, 2021 at 11:49:53PM +0300, Dmitry Kozlyuk wrote: > > Hi Tyler, > > > > 2021-07-08 12:21 (UTC-0700), Tyler Retzlaff: > > > hi folks, > > > > > > we would like to submit a a patch series that makes dll/dso for dpdk > > > work on windows. there are two differences in the windows platform that > > > would need to be address through enhancements to dpdk. > > > > > > (1) windows dynamic objects don't export sufficient information for > > > tls variables and the windows loader and runtime would need to be > > > enhanced in order to perform runtime linking. [1][2] > > > > When will the new loader be available? > > the solution i have prototyped does not directly export the tls variables > and instead relies on exports of tls offsets within a module. no loader > change or new os is required. > > > Will it be ported to Server 2019? > > not necessary (as per above) > > > Will this functionality require compiler support > > the prototype was developed using windows clang, mingw code compiles but > i did not try to run it. i suspect it is okay though haven't examine any > side-effects when using emul tls like mingw does. anyway mingw dll's > don't work now and it probably shouldn't block them being available with > clang. AFAIK it's the opposite. MinGW can handle TLS varibale export from DLL, although with "__emutls." prefix and some performance penalty. Clang can't at all, despite compiling and linking without an issue. No, it is not acceptable to add a generic feature supported by only one compiler. (FWIW, I'm displeased even by mlx5 being tied to clang.) Particularly, I don't understand how could MinGW and clang coexist if they export different sets of symbols. Apps will need to know if it's MingW- or clang-compiled DPDK? Sounds messy. > > (you mention that accessing such variables will be "non-trivial")? > > the solution involves exporting offsets that then allow explicit tls > accesses relative to the gs segment. it's non-trivial in the sense that > none of the normal explicit tls functions in windows are used and the > compiler doesn't generate the code for implicit tls access. the overhead > is relatively tolerable (one or two additional dereferences). A thorough benchmark will be required. I'm afraid that inline assembly (which %gs mention suggests) can impact optimization of the code nearby. Ideally it should be a DPDK performance autotest. > > > > > > (2) importing exported data symbols from a dll/dso on windows requires > > > that the symbol be decorated with dllimport. optionally loading > > > performance of dll/dso is also further improved by decorating > > > exported function symbols. [3] > > > > Does it affect ABI? > > the data symbols are already part of the abi for linux. this just allows > them to be properly accessed when exported from dll on windows. > surprisingly lld-link doesn't fail when building dll's now which it should > in the absence of a __declspec(dllimport) ms link would. > > on windows now the tls variables are exported but not useful with this > change we would choose not to export them at all and each exported tls > variable would be replaced with a new variable. > > one nit (which we will get separate feedback on) is how to export > symbols only on windows (and don't export them on linux) because similar > to the tls variables linux has no use for my new variables. There's already WINDOWS_NO_EXPORT mark in .map to generate .def, likewise, .map for Linux/FreeBSD could be generated from a basic .map with similar marks. > > > > It is also a huge code change, although a mechanical one. > > Is it required? All exported symbols are listed in .map/def, after all. > > if broad sweeping mechanical change is a sensitive issue we can limit > the change to just the data symbols which are required. but keeping in > mind there is a penalty on load time when the function symbols are not > decorated. ultimately we would like them all properly decorated but we > don't need to push it now since we're just trying to enable the > functionality. I was asking in connection with the previous question about ABI, because 21.11 ABI freeze may be a two-year one. Since ABI is not affected for Unix and for Windows we don't maintain it currently, there is no rush for the change at least.