From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f177.google.com (mail-wr0-f177.google.com [209.85.128.177]) by dpdk.org (Postfix) with ESMTP id 5C7C71396 for ; Thu, 16 Mar 2017 16:40:32 +0100 (CET) Received: by mail-wr0-f177.google.com with SMTP id g10so34761118wrg.2 for ; Thu, 16 Mar 2017 08:40:32 -0700 (PDT) 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=/rR7UNUQPJJqUqyjdEimdrOxtY0XKBE27OKIq2FhAj0=; b=H4l15ZrxixTzLDHnueIOsCLsLtKMffVmDk0+rnpLJD/psZYbCPfROXR+wzslk5VVm0 xu2RSLo81EGgC/wxB6LzNXd0Dwk241HFc1bJ46+iObG8i0ZV6BAX2nzE8sbS4aNIHvv9 67S85ShR6HUY8neeXXI1uRzm7eoupQfX8TkF+B6qyqA8qbwr9WTvveQays+dPXPCwDne SK9QHE+wCrgtiksPBHfQj8hnc7LyED0M0cjFi0BRLxA+FiVqqUV33mpLdz7eeIbw5RvA gfH2juVaXdyO9XJs+StNi9RdxttFvvj+Y1org8xAhjuIIccAIM16a0gNMQWiuOBpJuNP 8bXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=/rR7UNUQPJJqUqyjdEimdrOxtY0XKBE27OKIq2FhAj0=; b=SLDH388/oPsQtCygXSotH8MfJBiABlSzcfGdYBQKHFfApDPfV7FK+LhOEVBkqw1kN+ AVQWfRcMzyZbWaahgubhTqfPq4iVUT6T0V5sHHpyuo+fO1lyTbCkWNOz2FV5XohyjHeU cSWQTypwXQZh/13QPajWOb2QO91vhNOxHzf5V4B19h2ZJS18pXl1N+zHWwv3OzBIGgPy n4hqV78ea1pyYN++regwq6mIJnkpjHwVU6trNgDvTJgNzjNGisZ5sMMzvRFVOmnSPr6N ZU/NpaRl4ZWkP/gZZzrS46nB5CbkmXC722/4xv05JH4YY4WB+qv77ikf/Zpf43cjiGg/ xJpw== X-Gm-Message-State: AFeK/H0eHzl9PzSEhosUVvK0Ga5f67a42NYkbeoDqvwWJYnqZyyguDq4h89w+5/gL4+0hIa0 X-Received: by 10.223.173.76 with SMTP id p70mr8304401wrc.168.1489678831891; Thu, 16 Mar 2017 08:40:31 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id n14sm6621550wrn.28.2017.03.16.08.40.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 08:40:31 -0700 (PDT) From: Thomas Monjalon To: "Hunt, David" Cc: dev@dpdk.org, bruce.richardson@intel.com, nelio.laranjeiro@6wind.com Date: Thu, 16 Mar 2017 16:40:30 +0100 Message-ID: <2070887.ahJ85dIvpe@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: <1488791433-186137-2-git-send-email-david.hunt@intel.com> <11064293.gTtyHWn9o3@xps13> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v10 02/18] lib: create private header file 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: Thu, 16 Mar 2017 15:40:32 -0000 2017-03-16 10:43, Hunt, David: > On 15/3/2017 5:18 PM, Thomas Monjalon wrote: > > 2017-03-15 06:19, David Hunt: > >> +/** > >> + * Number of packets to deal with in bursts. Needs to be 8 so as to > >> + * fit in one cache line. > >> + */ > >> +#define RTE_DIST_BURST_SIZE (sizeof(rte_xmm_t) / sizeof(uint16_t)) > > error: 'rte_xmm_t' undeclared here (arm compilation) > > > > Can it be fixed by including rte_vect.h? > > > > Ideally I would prefer we stop using XMM types in a generic code. > > XMM are x86-only registers. It has been translated for other arches > > but we should use a more generic name. > > > > What was the intention here? SSE-optimized code or 128-bit size? > > Please check lib/librte_eal/common/include/generic/rte_vect.h > > for a generic type. > > Thomas, > > Including rte_vect.h does indeed resolve the issue. > > I had originally had "#define RTE_DIST_BURST_SIZE 8" but thought that latest > definition would give further clarity as to why it's set to 8. > > There are 2 reasons. > 1. The vector instruction I use for the matching works on 8 uint16s at a > time > 2. The (x86) cache lines communicating with the worker cores fit 8 mbuf > pointers at a time. > > So there are 2 options to resolve: > 1. #include at the top of rte_distributor_private.h > 2. revert back to "#define RTE_DIST_BURST_SIZE 8" > > Personally, I'd probably lean towards option 2 (with additional comment) > , as it removes > the mention of xmm from the generic header file, as well as being valid > for both > reasons, whereas the xmm #define really only helps to explain one reason. > > Do you have any preference? Let me know and I can push up a v11. > > Regards, > Dave. > > > P.S. Suggested change: > > /* > * Transfer up to 8 mbufs at a time to/from workers, and > * flow matching algorithm optimised for 8 flow IDs at a time > */ > #define RTE_DIST_BURST_SIZE 8 OK for the option 2