From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 50C19AD8F for ; Thu, 19 May 2016 18:07:31 +0200 (CEST) Received: by mail-wm0-f43.google.com with SMTP id a17so133547432wme.0 for ; Thu, 19 May 2016 09:07:31 -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=XoqsKHNyHuiEyB0RlCc/buAO1ni58x/Qc+6rlnQdiTc=; b=Y1lSbJeLB0tjIw2B7MoL0YBZQ3oMyFl36o7lMX86yrh4+xfhjQekLz/QtGrxan2LQk eJDKuc6dtcq5oW9dbAqE3lTFNzfn2HvTmf24Y1v3iEuzuXp3R5MSd8Hm3dsUwmb0f1u1 mGqLXk5p5Af5RlD42Ll3jPhY2crh5DuIwU1MNENnl9r/YBcQjvbpY4pY62coa2x4P9+f hKaF+pdKWdR5236TiqdvvRNecZdkqzkM2FlBnwsqkchqw67t3xw2PaWPWX4Ffa33t0Q1 DHljCQOjcK73EuXSQyFMIvvbO0sFbxOGW4RHYdffk7b9auhrrXYtCf7NpYqWXokhltmZ dEHQ== 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=XoqsKHNyHuiEyB0RlCc/buAO1ni58x/Qc+6rlnQdiTc=; b=mbt82yRINxi7Y1Eg0s86creYqj46D3XHPvfGRN6IpJ1QkBA/6V7FA8Cp3H2WUZAhXn tZd8FWf5xuOP7yUs3ZIpT5624+E44Y4jseujEmudstT1uDxP46IXI+ErD1RmKOtW2GXj LwZzJDms7YXSrN/ug6ZzO7XqpPvMhylH9Ui1I2yhteBf9W1PUDZQpouSKn9WQcDom/Gb gPd78JIRY5Kp+qijfUpehNc/KEtGhgHP++l3HSbVgBkDLYTF5w/rQzWBrGfyGZbp1ktU y/KBS4hOEL2m9an/9gB96g7ilj/xc9YLISdhiLcefAvgTFYKczdlWx2zPHBVFpMc1maK kkEQ== X-Gm-Message-State: AOPr4FVeNYoem4dCTLE5QM0MA5BRMtb40AuZvS0s8uzSPo5G1vSlWCcGIGXFF0YnxHfXD8eW X-Received: by 10.194.242.167 with SMTP id wr7mr14387808wjc.145.1463674049964; Thu, 19 May 2016 09:07:29 -0700 (PDT) Received: from xps13.localnet (113.202.154.77.rev.sfr.net. [77.154.202.113]) by smtp.gmail.com with ESMTPSA id r5sm15100059wjy.37.2016.05.19.09.04.54 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 May 2016 09:07:29 -0700 (PDT) From: Thomas Monjalon To: Jerin Jacob Cc: "Ananyev, Konstantin" , "Richardson, Bruce" , dev@dpdk.org, "viktorin@rehivetech.com" , "jianbo.liu@linaro.org" Date: Thu, 19 May 2016 17:50:27 +0200 Message-ID: <9650772.iYDeGtr74X@xps13> User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20160519133548.GA5308@localhost.localdomain> References: <1463579863-32053-1-git-send-email-jerin.jacob@caviumnetworks.com> <2601191342CEEE43887BDE71AB97725836B5AB67@irsmsx105.ger.corp.intel.com> <20160519133548.GA5308@localhost.localdomain> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] mbuf: make rearm_data address naturally aligned 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, 19 May 2016 16:07:31 -0000 2016-05-19 19:05, Jerin Jacob: > On Thu, May 19, 2016 at 12:18:57PM +0000, Ananyev, Konstantin wrote: > > > On Thu, May 19, 2016 at 12:20:16AM +0530, Jerin Jacob wrote: > > > > On Wed, May 18, 2016 at 05:43:00PM +0100, Bruce Richardson wrote: > > > > > On Wed, May 18, 2016 at 07:27:43PM +0530, Jerin Jacob wrote: > > I wonder does anyone really use mbuf port field? > > My though was - could we to drop it completely? > > Actually, after discussing it with Bruce offline, an interesting idea came out: > > if we'll drop port and make mbuf_prefree() to reset nb_segs=1, then > > we can reduce RX rearm_data to 4B. So with that layout: > > > > struct rte_mbuf { > > > > MARKER cacheline0; > > > > void *buf_addr; > > phys_addr_t buf_physaddr; > > uint16_t buf_len; > > uint8_t nb_segs; > > uint8_t reserved_1byte; /* former port */ > > > > MARKER32 rearm_data; > > uint16_t data_off; > > uint16_t refcnt; > > > > uint64_t ol_flags; > > ... > > > > We can keep buf_len at its place and avoid 2B gap, while making rearm_data > > 4B long and 4B aligned. > > Couple of comments, > - IMO, It is good if nb_segs can move under rearm_data, as some > drivers(not in ixgbe may be) can write nb_segs in one shot also > in segmented rx handler case > - I think, it makes sense to keep port in mbuf so that application > can make use of it(Not sure what real application developers think of > this) I agree we could try to remove the port id from mbuf. These mbuf data are a common base to pass infos between drivers and apps. If you need to store some data which are read and write from the app only, you can have use the private zone (see rte_pktmbuf_priv_size). > - if Writing 4B and 8B consume same cycles(at least in arm64) then I think it > makes sense to make it as 8B wide with maximum pre-built constants are possible. > > > > > Another similar alternative, is to make mbuf_prefree() to set refcnt=1 > > (as it update it anyway). Then we can remove refcnt from the RX rearm_data, > > and again make rearm_data 4B long and 4B aligned: > > > > struct rte_mbuf { > > > > MARKER cacheline0; > > > > void *buf_addr; > > phys_addr_t buf_physaddr; > > uint16_t buf_len; > > uint16_t refcnt; > > > > MARKER32 rearm_data; > > uint16_t data_off; > > uint8_t nb_segs; > > uint8_t port; > > The only problem I think with this approach is that, port data type cannot be > extended to uint16_t in future. It is a major problem. The port id should be extended to uint16_t.