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 04D22A0547; Mon, 19 Jul 2021 11:12:16 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 72F704069D; Mon, 19 Jul 2021 11:12:16 +0200 (CEST) Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) by mails.dpdk.org (Postfix) with ESMTP id 4A1164068B for ; Mon, 19 Jul 2021 11:12:15 +0200 (CEST) Received: by mail-lj1-f169.google.com with SMTP id q4so25213372ljp.13 for ; Mon, 19 Jul 2021 02:12:15 -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=bj90E8GEEF2SBC1yo+hyu8KUtR/RnVQZXVcS3j83Us0=; b=pm9ZoYAWUwP/xt0iedfLtNs6WxbuJqI6o2Uis1NPs+3qfMvrWpMVvYDC0cEQrCku6I CKZ0DKkHfqOD0jNNyYTcvV7LjwHSQH/Q2amsMFBWiFELZP7+ADzIMN70Sd9sR3WRhgp9 fN9dgxJah1aW8DiAKAEwBGS/AvrxkmEqszHfTNrJ/WWM2ihX51vuTilmvTud/YO5frSm jdNfMVlLShrzsVVzfok6hDMxFXQn8MACseaKIQbyzz5bHKdgtB9sU9/9UrpJgCTXxFxY zsDKRETUhweDtpoL6wdFa03p4G2u5JWg2SRUAWKT+mYjj5/VsJWpT/VoUBSFLGu38psI cX9A== 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=bj90E8GEEF2SBC1yo+hyu8KUtR/RnVQZXVcS3j83Us0=; b=JkPeynd55gDP6k4jtDLJ7MMLQis+qztxLjVNxUorX9FYp+Q4TgCbfdtGcyj1lLBME/ nFrYFmMNJPTxkdYvlO46ojia5i2ZhGLZim3ixnrCte7kLop5I+Lkvv9dryDLdhFBrpVl tCSIc8bVF0d8x4l32BkMXX9+qEvixRR7zMckZGZxhsPw8sKgXXc5XoOzS7syYGxxiWy4 QCxqcd6HHg1Y6R/aSmWZD9F4saVE82x4Lgovt+vJUbXofC5VoUNoqDhzFjgso6l9lrUY NwK3gS3Aibl5bBgmxwy6d92knMj8mIYjA1kQG9atdKeVKNImbt2nS5CEdTqjlSgxB6wW KYFA== X-Gm-Message-State: AOAM53354g9zePIrRGjttP8p4+PpyP42hBNXTUvgII5iVOi75pcjzFu9 lre9vaGZUp43yeVnZ3usMoU= X-Google-Smtp-Source: ABdhPJwjUq1WC/JZOG86PmcbmlxjWNlJG9rJZwaIFdpYgdom30en7C+raGMvOTamdH/C1wQ/+41j+Q== X-Received: by 2002:a2e:924d:: with SMTP id v13mr21811291ljg.369.1626685934683; Mon, 19 Jul 2021 02:12:14 -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 bt42sm1236589lfb.9.2021.07.19.02.12.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Jul 2021 02:12:13 -0700 (PDT) Date: Mon, 19 Jul 2021 12:12:12 +0300 From: Dmitry Kozlyuk To: Tyler Retzlaff Cc: dev@dpdk.org, thomas@monjalon.net Message-ID: <20210719121212.6d78b06c@sovereign> In-Reply-To: <20210719034541.GA1949@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> <20210716124035.51741861@sovereign> <20210719034541.GA1949@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-18 20:45 (UTC-0700), Tyler Retzlaff: > On Fri, Jul 16, 2021 at 12:40:35PM +0300, Dmitry Kozlyuk wrote: > > 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. > > mingw emutls just makes it compile allowing the variables to be exported, > the binaries still won't work without loader support. or are you saying > they do? > > > > > 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. > > it doesn't seem reasonable to reject the feature because mingw may or > may not work. mingw binaries are not worse off if the feature can be > enabled with clang. either way it is untested i am uncertain if it will > work with mingw and have no time budget to test it. if it made mingw > built binaries "worse" i would agree with you but the worst case > scenario is that it works exactly as well as it does now. My mistake, I thought we exported __emutls.VARNAME symbols (in which case MinGW DLLs would work without loader change). Since we don't, then you're right, we have the same set of exported symbols and can enable this feature. I'm willing to share the effort and help with MinGW. > > > > > > > (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. > > no inline assembly is used, only compiler intrinsics which is superior > because it allows the compiler an opportunity to perform optimization > which inline assembly does not. whether or not clang or mingw will > optimize i have no idea. this is aside from the expected additional code > generated for cross dll boundary accesses. > > let's catch up at the sync and discuss your concerns. I think there are none left, unless you have some. Waiting for you to post the actual code.