From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 885551B65A for ; Fri, 13 Oct 2017 09:36:25 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2084C209FC; Fri, 13 Oct 2017 03:36:25 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 13 Oct 2017 03:36:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=VV7n48Kb40vxw54CgHXaSzCiSI HmzsOG0CcCjQwJliM=; b=VM1Vvw4EEsoj1Nd8OmEekduz9/p6Cu2cr5dnm9hIJG 712v+Db4fRoq82YPUvX9nuL1HWoLKdJUFAdG5C3+QDrZtH1a5M8GwdOqR4Zx6Trc ntUkj42B09QKNayUr3kDxJKLzXjajHPpDnBFyOLPrN4bFTFThW0ONXQlG6f+hHdd o= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=VV7n48 Kb40vxw54CgHXaSzCiSIHmzsOG0CcCjQwJliM=; b=O+A86KNzZYeKvjXNeqygYf LGhQQ3ztbsLFQyaWlW4wH/w42Txn2UZ4W7FnZEGPctDnA58V+AaCcfopYyNaSBzS BwLn7Ffr9boB1WcRByg9kpEsyDTIXPD8/qdqc4v74rBEHyi6jxj51SBjCV06hW7r 3gjPiV55UjT4kCCsJmP+2nlGbOkde8famc4Ldc+o/+gRDQnzLKLrAVhYbDiGwF4+ oaZ9SJEqZim0FEvk/pvz/yFdLjVSTdObk96QPKCv/BXsasXI70lo5f3uFFGoaMMc 4lejSfAfRYIHem7kFl8dFU0acDjEcO7+9bzHT8re4JmS8nQIjmuo0s8I8np3CD+A == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id C589D7F955; Fri, 13 Oct 2017 03:36:24 -0400 (EDT) From: Thomas Monjalon To: "Ananyev, Konstantin" , "Li, Xiaoyun" Cc: dev@dpdk.org, "Richardson, Bruce" , "Lu, Wenzhuo" , "Zhang, Helin" Date: Fri, 13 Oct 2017 09:36:24 +0200 Message-ID: <5529102.6cLtonmahJ@xps> In-Reply-To: <2601191342CEEE43887BDE71AB9772585FAA89A1@IRSMSX103.ger.corp.intel.com> References: <1507157911-8702-1-git-send-email-xiaoyun.li@intel.com> <1709550.5v5ZG7JxHL@xps> <2601191342CEEE43887BDE71AB9772585FAA89A1@IRSMSX103.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v7 1/3] eal/x86: run-time dispatch over memcpy 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: , X-List-Received-Date: Fri, 13 Oct 2017 07:36:25 -0000 13/10/2017 09:31, Ananyev, Konstantin: > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > 13/10/2017 03:06, Li, Xiaoyun: > > > Hi > > > Sorry for the late reply. I took AL last 3 days. > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > > 05/10/2017 14:33, Xiaoyun Li: > > > > > +/** > > > > > + * Macro for copying unaligned block from one location to another > > > > > +with constant load offset, > > > > > + * 47 bytes leftover maximum, > > > > > + * locations should not overlap. > > > > > + * Requirements: > > > > > + * - Store is aligned > > > > > + * - Load offset is , which must be immediate value within > > > > > +[1, 15] > > > > > + * - For , make sure bit backwards & <16 - offset> bit > > > > > +forwards are available for loading > > > > > + * - , , must be variables > > > > > + * - __m128i ~ must be pre-defined */ #define > > > > > +MOVEUNALIGNED_LEFT47_IMM(dst, src, len, > > > > > > > > Naive question: > > > > Is there a real benefit of using a macro compared to a static inline function > > > > optimized by a modern compiler? > > > > > > > The macro is in the existing DPDK codes. I didn't touch it. I just change the file name and the function name to rte_memcpy_internal. > > > So I am not clear about if there is real benefit. > > > In my opinion, I think it is the same as static inline function. > > > > > > Do I need to change them to inline function? > > > > In this patch, it appears as a new macro. > > Ah no, it definitely been there before. > All we did here - git mv rte_memcpy.h rte_memcpyu_interlan.h > and then in rte_memcpy_internal.h renamed rte_memcpy() to rte_memcpy_internal(). > > > If you can, inline function is cleaner for the new one. > > I don't think it will be straightforward - one of the parameters is a constant value. > My preference would be to keep original rte_memcpy() code intact as much as we can here > (except probably cosmetic changes - indentation, line length fixing etc.). > After all that patch is for adding architecture function selection at runtime only. > If we like to improve our rte_memcpy() any furher - NP with that, but let it be a > separate patch. OK I am waiting this patch to close RC1 today.