From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) by dpdk.org (Postfix) with ESMTP id 847292B93 for ; Mon, 4 Jul 2016 14:58:48 +0200 (CEST) Received: by mail-wm0-f46.google.com with SMTP id r201so114624057wme.1 for ; Mon, 04 Jul 2016 05:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=FZEuCyHUQ4s+1MIlwRix4zv5C2Nh4jT3J/+OcRML9d8=; b=mies+9TX7FiNoMfis6ZOQT3YQFyMx6ISZzQ69iUPCbgh5RasYzcm/ARMfV4Y7BQUPO EVA6E3Hyjy/YTM9ZExA077xPnhrYQ97amMRxgA2tC3+RmvtfS/hqo92AGlaJm/O78+3r IvB2vU9F+VTh89pYJAVqJlWwhThcwII8Sn5P7yvUTXXEM3E5TwASrRCUHzwxMbBBmCwf NtghaTQyJ095MGqm568u6jiujd91I4uV2W01XEjVOxVk7yiFPzy6os3DGcteu+OCg89C O3RxxAI/STSMK0XItO9L8N4AxbGSsr4xV6JVoYzrsyT5LezfQbkhgJdQ3fu5U7CIhpXs jYVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=FZEuCyHUQ4s+1MIlwRix4zv5C2Nh4jT3J/+OcRML9d8=; b=gD0OVm7JrItjjZSyydzh5silia+jdDnDoG7Ef6RwvlPFEK/ZS1UGr2DkTHE2rqX1ne nNwewRNWgygaeXc/ZG2chyFru5xBSLBw9koW6IgprTMEGqBOj5T+SGkzRhLI/2wQ5Vae Pe1/ndxTmytpN/wZihWT6vBKAThO9w8wUr/5RJSDBRAkBPefgZu2HO44aG/Iui93veVj YS4LxD4lzbg98Po3rUVJnpe87Rwd4h3FS+iy/cgwzHSrELEViRuJnrJuOjghTG9tSWSW LSDob2V70ImA4e+HB4vAHLoEPTGGJX+aS8gXDAvnovj473Kz8O2LyUCfB+Wqa923ZC9H A0sg== X-Gm-Message-State: ALyK8tKjLMEibpTBxE0dm/N5xyG90ciWUNe7NNplBpEYzuxVJpVbMmcDtp6nYZBzt7/FLXMg X-Received: by 10.28.17.132 with SMTP id 126mr10966556wmr.90.1467637128196; Mon, 04 Jul 2016 05:58:48 -0700 (PDT) Received: from [192.168.1.15] (LFbn-1-8274-170.w81-254.abo.wanadoo.fr. [81.254.171.170]) by smtp.gmail.com with ESMTPSA id m5sm3274703wmm.10.2016.07.04.05.58.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Jul 2016 05:58:47 -0700 (PDT) To: Jerin Jacob References: <1463579863-32053-1-git-send-email-jerin.jacob@caviumnetworks.com> <2601191342CEEE43887BDE71AB97725836B5AB67@irsmsx105.ger.corp.intel.com> <20160519133548.GA5308@localhost.localdomain> <9650772.iYDeGtr74X@xps13> <5742E752.3090207@6wind.com> <20160704124540.GA5788@localhost.localdomain> Cc: Thomas Monjalon , "Ananyev, Konstantin" , "Richardson, Bruce" , dev@dpdk.org, "viktorin@rehivetech.com" , "jianbo.liu@linaro.org" From: Olivier MATZ Message-ID: Date: Mon, 4 Jul 2016 14:58:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160704124540.GA5788@localhost.localdomain> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Mon, 04 Jul 2016 12:58:48 -0000 Hi Jerin, On 07/04/2016 02:45 PM, Jerin Jacob wrote: > On Mon, May 23, 2016 at 01:19:46PM +0200, Olivier Matz wrote: >> Hi, >> >> On 05/19/2016 05:50 PM, Thomas Monjalon wrote: >>> 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). >> >> At the first read, I was in favor of keeping the port_id in the >> mbuf. But after checking the examples and applications, I'm not >> opposed to remove it. Indeed, this information could go in an >> application-specific part or it could be an additional function >> parameter in the application processing function. >> >> The same question could be raised for nb_seg: it seems this info >> is not used a lot, and having a 8 bits value here also prevents from >> having long chains (ex: for socket buffer in a tcp stack). >> >> Just an idea thrown in the air: if these 2 fields are removed, it >> brings some room for the m->next field to go in the first cache line. >> This was mentioned several times (at least [1]). >> >> [1] http://dpdk.org/ml/archives/dev/2015-June/019182.html > > > Can we come to some consensus on this for this release. The original problem was > mbuf->rearm_data not being natually aligned and the assosiated performacnce > issues with ARM architecture for non naturally aligned access. > I believe that is fixing in this patch without any performance degradation on IA. > I believe that is a good progress. Can we make further mbuff improvements as > a additional problem to solve. > > Thoughts ? Changing the mbuf topology is something that should happen as rarely as possible, so I think we should group all mbuf modifications in one version. Your issue (mbuf->rearm alignment), the removing of uneeded fields (port id, maybe nb_segs), and possibly other things should be addressed for next version (16.11). I'll send a deprecation notice before the 16.07 is out if there is no opposition. Regards, Olivier