From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: [PATCH] mbuf: replace c memcpy code semantics with
	optimized rte_memcpy
Date: Fri, 27 May 2016 17:05:45 +0200
Message-ID: <4125316.GWKk7IhZzc@xps13>
References: <1464101442-10501-1-git-send-email-jerin.jacob@caviumnetworks.com>
 <57482079.1050605@intel.com> <20160527114205.GA15118@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: "Hunt, David" <david.hunt@intel.com>, Olivier Matz <olivier.matz@6wind.com>,
 dev@dpdk.org, bruce.richardson@intel.com, konstantin.ananyev@intel.com
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46])
 by dpdk.org (Postfix) with ESMTP id 100D75A95
 for <dev@dpdk.org>; Fri, 27 May 2016 17:05:47 +0200 (CEST)
Received: by mail-wm0-f46.google.com with SMTP id n129so141064837wmn.1
 for <dev@dpdk.org>; Fri, 27 May 2016 08:05:47 -0700 (PDT)
In-Reply-To: <20160527114205.GA15118@localhost.localdomain>
List-Id: patches and discussions about DPDK <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>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

2016-05-27 17:12, Jerin Jacob:
> IMHO, I think we should have means to abstract this _logical_ changes
> under conditional compilation flags and any arch/platform can choose
> to select what it suites better for that arch/platform.
> 
> We may NOT need to have frequent patches to select the specific
> configuration, but logical patches under compilation flags can be accepted and
> each arch/platform can choose specific set configuration when we make
> the final release candidate for the release.
> 
> Any thoughts?

Yes having some #ifdefs for arch configuration may be reasonnable.
But other methods must be preffered first:
1/ try implementing the function in arch-specific files
2/ and check at runtime if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_X
3/ or check #ifdef RTE_MACHINE_CPUFLAG_X
4/ or check #ifdef RTE_ARCH_Y
5/ or check a specific #ifdef RTE_FEATURE_NAME to choose in config files

The option 2 is a nice to have which implies other options.

Maybe that doc/guides/contributing/design.rst needs to be updated.