From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by dpdk.org (Postfix) with ESMTP id D87D28032 for ; Thu, 4 Dec 2014 14:47:28 +0100 (CET) Received: by mail-wi0-f174.google.com with SMTP id h11so34776746wiw.13 for ; Thu, 04 Dec 2014 05:47:28 -0800 (PST) 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:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=Eym0gODn6+Om/mDa6xDdoaFKusrUzdKRub7sW16AhhE=; b=fLe9d+pmGVOvqm1tY/QUc2fluZTK8hDz/PumNey9pthDrmevuTQC4g7tFtBpWOyRUa tro/eMtvyjNZeAmJdi7f/kLZaFVSQaoa5OUJhQ+G22oxeVXRxHH8OnhkfX2mvsP3IXmY tazUkGs6e3XjbzD2tAv/mBGh2d2LNTj6zJIhMO0anlfjFCFscjKkzrccpiSaimQos7fP 21k+gk3csB88IipQZenHuQ135VZMpXmokEADhhnBLZUrEyOk593cTAvi53Z1vAbdRp2J Suh4cJgivDOjLamgZvhACY5boVZtHUMte0uzsliQVUTsciVdjdbrQkyYu3NhIeNAHf8T n+lg== X-Gm-Message-State: ALoCoQkAK04b2JKLs+3c5BFT1Q0W+/L9HbUgfXGUFTioWG0cLNscFtXkRm6zJRjtwQnjft5aaILR X-Received: by 10.194.216.170 with SMTP id or10mr12705292wjc.96.1417700848701; Thu, 04 Dec 2014 05:47:28 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id ud1sm40592527wjc.7.2014.12.04.05.47.27 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Dec 2014 05:47:27 -0800 (PST) From: Thomas Monjalon To: Neil Horman Date: Thu, 04 Dec 2014 14:47:03 +0100 Message-ID: <1795169.cqFrYtuj77@xps13> Organization: 6WIND User-Agent: KMail/4.14.3 (Linux/3.17.4-1-ARCH; KDE/4.14.3; x86_64; ; ) In-Reply-To: <20141204132939.GB16249@hmsreliant.think-freely.org> References: <1417688048-23076-1-git-send-email-chaozhu@linux.vnet.ibm.com> <1950672.AxEg8fkUWW@xps13> <20141204132939.GB16249@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org, Chao Zhu Subject: Re: [dpdk-dev] [PATCH] Fix KNI compiling issue on IBM Power X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 13:47:29 -0000 2014-12-04 08:29, Neil Horman: > On Thu, Dec 04, 2014 at 12:59:31PM +0100, Thomas Monjalon wrote: > > > Because of different cache line size, the alignment of struct > > > rte_kni_mbuf in rte_kni_common.h doesn't work on IBM Power. This patch > > > changed from 64 to RTE_CACHE_LINE_SIZE micro to do the alignment. > > > > > > Signed-off-by: Chao Zhu > > > > Acked-by: Thomas Monjalon > > > > Applied > > > Woah! Slow down here, I'm not sure if this makes sense to fix his way. The > exact same ifndef/define/endif construct is used for this macro in rte_memory.h. > Currently their defined to the same vaule, but if that ever changes, this macro > will return different values based on the order in which header files are > included. That doesn't seem appropriate at all. I agree (was my comment) but the patch was applied as a hot fix. A better fix has to be found for DPDK 2.0. Do you agree this fix is enough for DPDK 1.8 release? > > I wonder if we could try to guess the cache line size instead of > > configuring it in many places. > > Maybe we could use something like sysconf(_SC_LEVEL1_DCACHE_LINESIZE)? > > > This is a good idea, but I think its a bit broken for a few reasons: > > 1) _SC_LEVEL1_DCACHE_LINESIZE I don't think is POSIX mandated, so there is every > possibility that the above won't work on BSD > > 2) While getting the cache line size dynamically is a great idea, dpdk has > several locations that size structures based on processor cache line size, which > implicitly requires a static cache line definition. It can be guessed dynamically in the first build step (kind of configure). > It seems the right thing to do, in my mind is to define RTE_CACHE_LINE_SIZE per > arch (perhaps in common/include/arch//rte_.h), then just let > the build break if a given arch doesn't define it (i.e. make definig that value > an arch reqirement). It's the other option. For IBM Power, it's currently overwritten in the Makefile: http://dpdk.org/browse/dpdk/tree/mk/arch/ppc_64/rte.vars.mk Thanks for helping to find a better solution. -- Thomas