From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id EBC86A051C; Sun, 9 Feb 2020 22:39:42 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DC1261BEE2; Sun, 9 Feb 2020 22:39:41 +0100 (CET) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) by dpdk.org (Postfix) with ESMTP id BB9281BDAE for ; Sun, 9 Feb 2020 22:39:39 +0100 (CET) Received: by mail-lj1-f181.google.com with SMTP id a13so4846912ljm.10 for ; Sun, 09 Feb 2020 13:39:39 -0800 (PST) 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=CzoFLaSFAbYCBgvtzSLouhxTxvwHXZPRzWi0ykXI7nU=; b=pUBFqNzOQKghbrZlw6iPDgTwH4llMM1VNEaT1pDVqpsGWG/I1+3IapMG339XATRAap U5eRtuaEXU+RCDb4yJf4/kft+QQFHdmoP46JsIU9fEpvAgdJIwrC3MUAFja0NE3qz+pf JfU6bZ4W0DkniWBzhh+ahKTTUVBWzqs9MsqjQ6zY0sO9/Y/jzwe1kLpeole5+t/NvkdE zA1UnCDHFZCiBbWbXXEgxgF5GgjJaRHm5MBDimndYtXfxQ+mWrXaZSbr104Bom/4/3uG JnXGOFcKndFnedf4TctbG0iSTAiuCticIAvxTpvjnKQwB8PlMYKTYAF/+Z5IuXMEL2YI HjPQ== 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=CzoFLaSFAbYCBgvtzSLouhxTxvwHXZPRzWi0ykXI7nU=; b=J+phQEPQoTak6Y/OEq/PlqhrPvToUD2LGjaRbf4dAlm/R7KKdpjFaOmNmoHqVAJpEQ puedBhRSDCH4bqcpqBgktWymVIHZF1jUBWdBtKEB3aAXjvVWJ2SmyVIYYp4eRDAyqbv4 JoWox7dZUQ5altu3movl218nPtv+Xgb75zRuoCwfDnINnUv8qs4ozeBKLWoFaHztFsPJ S/zvmtgwLXfau6h5d2Ut5SQTiyOK2lcFJTz6rDTneIE4ngsVanGU+kcU4bsot4ZIu+3Q okuDhR6qK6hkmYMrUewL/PmIkudwyGAizhpVk5BxAQTelMQzj4X9VXn+WnhIH/FDFl88 g1uQ== X-Gm-Message-State: APjAAAW2Y+G8NWyM1Oexy0G1X877nTImao0fOUlIQ2EnJMRClfujks40 EckW/EVVDVUYKL1Or5AnP5c= X-Google-Smtp-Source: APXvYqxACfs/ouJ6rv5q+ucnaqyKRSZnC9bWI/7QTDc2NMLwouazC39ION+FaDlApNkBEaryu8jlCQ== X-Received: by 2002:a2e:3619:: with SMTP id d25mr5860026lja.231.1581284379146; Sun, 09 Feb 2020 13:39:39 -0800 (PST) Received: from Sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id w3sm5186204ljo.66.2020.02.09.13.39.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Feb 2020 13:39:38 -0800 (PST) Date: Mon, 10 Feb 2020 00:39:37 +0300 From: Dmitry Kozlyuk To: Thomas Monjalon Cc: dev@dpdk.org, Harini Ramakrishnan , Omar Cardona , Pallavi Kadam , Ranjit Menon , John McNamara , Marko Kovacevic , Tal Shnaiderman Message-ID: <20200210003937.7dcdcc82@Sovereign> In-Reply-To: <3267218.V25eIC5XRa@xps> References: <20200131030744.19596-1-dmitry.kozliuk@gmail.com> <2467193.BddDVKsqQX@xps> <20200205025728.4562e90b@Sovereign> <3267218.V25eIC5XRa@xps> X-Mailer: Claws Mail 3.17.4 (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] [PATCH 6/6] doc: guide for Windows build using MinGW-w64 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" > I think the strategy should be to progress on both GCC and Clang > at the same time. Remembered another issue: thread-local storage (TLS) with shared libraries. Windows PE doesn't support TLS via special sections, so compilers use TLS emulation layer. With static libraries, there are no issues described below. The first aspect is a build-time issue of MinGW. When linking to DPDK shared libraries, errors occur: undefined reference to `__emutls_v.per_lcore__rte_errno' undefined reference to `__emutls_v.per_lcore__rte_lcore_id' DPDK declares per_lcore__XXX in a map file, but GCC places __thread symbols in __emutls_v section, so the proper name to export becomes __emutls_v.XXX. This can be worked around by using an additional version script with MinGW, as I do in my port [0], however, the proper solution would be fixing the bug on MinGW side [1]. MinGW already converts TLS variable names when generating DEF files with `-Wl,--output-def` option (not used by DPDK, just a hint). The second aspect is performance. Per [2], Win32 API TLS functions are ~10% slower than non-emulated access on Linux, and MinGW emulation layer slows access by another 20% (30% total). Clang emulation code is similar to MinGW's [3], although I wasn't able to find any benchmarks. As a DPDK user, I know that rte_lcore_id() is heavily used on the data-path, so this is severe. My opinion is, for the first time Windows port should use whatever TLS implementation the compiler provides, then attempt optimization. It should be possible, because we don't need a general-purpose TLS, but only TLS for EAL threads. [0]: https://github.com/PlushBeaver/dpdk/blob/windows/lib/meson.build#L174 [1]: https://sourceforge.net/p/mingw-w64/bugs/827/ [2]: https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/d72aad95-b6aa-af03-667b-5898456a5a63@gmx.com/ [3]: https://github.com/llvm-mirror/compiler-rt/blob/master/lib/builtins/emutls.c > Please Dmitry, would you like to review Pallavi's patches > in order to make them coexist with yours? Done. There are no logical conflicts, if code conflicts occur after merging Pallivi's patchset, I'll resolve them before sending v3. -- Dmitry Kozlyuk