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/.