From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas.monjalon@6wind.com> Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id 28FE858C8 for <dev@dpdk.org>; Fri, 2 Dec 2016 11:25:26 +0100 (CET) Received: by mail-wm0-f51.google.com with SMTP id f82so11489630wmf.1 for <dev@dpdk.org>; Fri, 02 Dec 2016 02:25:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=cGzPUbxYSnmQVfQCXHUYlR5KDTVRLV6l+uUkAOxyMes=; b=XzBhaLkkNf8uNrM2EsLO9A3LpNWswkVO/MQYGVIVES1DsuKeaJ2Sr9Ffr3KD5sW+Yh KTK7OcfD5aUwgQHsyw6y5UpbArfAACd3KKAFrwoXnrY83pcOKZ6fBAAt539HxQ8FosTE kIJkHdGYEQnt/AdEJC/Ic2s4zpbf8kZwZkHmQ/RRuJHxd4YX70xKk59cW6bE5NnFzZXQ So+B4sRllQeCohdY8ZZyhTGGr2b70cftB9zegik3GzC1N/o8/9s+qLJXN3QIxMpQaWC+ Lz1kORUn4rpw/A5OoUhwSyVfad2J3aeF1G8m10VpqKG0vO7vvTAlc8myyjKXdMPNY2m9 t4hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=cGzPUbxYSnmQVfQCXHUYlR5KDTVRLV6l+uUkAOxyMes=; b=WXFIwkW3HgfZpHQ7b89sBnZheexTcIjYp8G+rEyiUyjGJYIugXmQETW5YM+COR92dq kNOovao1o2LGE9pIvQNvoclzvSMoDQWDq770+LHvaaaldscxEiOz3Fg98OFEats4sys4 /TFP2zNW/sZ9QR6CB995mtZFCTln/57rWeUMsmcB3kMYC5cwhV8UNAUWpFQMC+swEuqc oJ/5tGNC6WYciZfNGenjAZK3q3D5+KebdI/4AAQHWCwQcfqeoiz8LRpei1Tm5TOUQ5Fv kblpt5U2fVWHGwmTtvc2cwU7epKrpMPjiRzqGPdQzoFGIWg1fCc1fV7AVehtbCdNWqk8 fwgw== X-Gm-Message-State: AKaTC01jlMDGCeiVEfvjPQZwjELYeZizpokhB24s8yYNszQR6CTFk+fMr8JpGJ/XbdmGrZ01 X-Received: by 10.28.152.79 with SMTP id a76mr2262361wme.47.1480674326662; Fri, 02 Dec 2016 02:25:26 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id xu5sm4743040wjc.49.2016.12.02.02.25.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Dec 2016 02:25:25 -0800 (PST) From: Thomas Monjalon <thomas.monjalon@6wind.com> To: Zhiyong Yang <zhiyong.yang@intel.com> Cc: dev@dpdk.org, yuanhan.liu@linux.intel.com, bruce.richardson@intel.com, konstantin.ananyev@intel.com, Pablo de Lara <pablo.de.lara.guarch@intel.com> Date: Fri, 02 Dec 2016 11:25:25 +0100 Message-ID: <7223515.9TZuZb6buy@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <1480926387-63838-2-git-send-email-zhiyong.yang@intel.com> References: <1480926387-63838-1-git-send-email-zhiyong.yang@intel.com> <1480926387-63838-2-git-send-email-zhiyong.yang@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 1/4] eal/common: introduce rte_memset on IA platform X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Fri, 02 Dec 2016 10:25:27 -0000 2016-12-05 16:26, Zhiyong Yang: > +#ifndef _RTE_MEMSET_X86_64_H_ Is this implementation specific to 64-bit? > + > +#define rte_memset memset > + > +#else > + > +static void * > +rte_memset(void *dst, int a, size_t n); > + > +#endif If I understand well, rte_memset (as rte_memcpy) is using the most recent instructions available (and enabled) when compiling. It is not adapting the instructions to the run-time CPU. There is no need to downgrade at run-time the instruction set as it is obviously not a supported case, but it would be nice to be able to upgrade a "default compilation" at run-time as it is done in rte_acl. I explain this case more clearly for reference: We can have AVX512 supported in the compiler but disable it when compiling (CONFIG_RTE_MACHINE=snb) in order to build a binary running almost everywhere. When running this binary on a CPU having AVX512 support, it will not benefit of the AVX512 improvement. Though, we can compile an AVX512 version of some functions and use them only if the running CPU is capable. This kind of miracle can be achieved in two ways: 1/ For generic C code compiled with a recent GCC, a function can be built for several CPUs thanks to the attribute target_clones. 2/ For manually optimized functions using CPU-specific intrinsics or asm, it is possible to build them with non-default flags thanks to the attribute target. 3/ For manually optimized files using CPU-specific intrinsics or asm, we use specifics flags in the makefile. The function clone in case 1/ is dynamically chosen at run-time through ifunc resolver. The specific functions in cases 2/ and 3/ must chosen at run-time by initializing a function pointer thanks to rte_cpu_get_flag_enabled(). Note that rte_hash and software crypto PMDs have a run-time check with rte_cpu_get_flag_enabled() but do not override CFLAGS in the Makefile. Next step for these libraries? Back to rte_memset, I think you should try the solution 2/.