From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com [209.85.128.170]) by dpdk.org (Postfix) with ESMTP id 16CE3591E for ; Tue, 21 Feb 2017 10:54:09 +0100 (CET) Received: by mail-wr0-f170.google.com with SMTP id 89so74077119wrr.3 for ; Tue, 21 Feb 2017 01:54:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=VRALeAJJ1KwrYzCgM6/UDN13M/BM3mthvdDmEAOZfYM=; b=RzdeD7TK/mdyvqwSdxC9w5ksW040IuolifGfcbTj217m2FRWU9SG7lkkcSvsJWwOj1 NJSpOxLsFjdnf10RiH1RUiSNYSV0kNzf+00bVhrEEW93xygdSFYt344CwSIXOnBoeJyc ZeBthZ0zEucQFMj1Xf+Tseix4hmjr3cFpcJBa/BDwcLKdcES+HmTkISuerzUBhy5BN3n K8dqv4o1mCwAgeNFeQ2rPxF7ylhisOw5cBD4jJHDUKFjxo/n+ZdaJAAIegVdPtG7isOW If4bilafxSb58VyCVILcd1gjat/hYbbcSBlQ2bR/+Z1xr8ev0lo+fFEGQEdMgSdtCQp0 Qh4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=VRALeAJJ1KwrYzCgM6/UDN13M/BM3mthvdDmEAOZfYM=; b=MkKvTKMtQIqHqoAQVMhhkWTouRb37jGp4qV4YdJI+5TaebC4awBntoPgJLdbBAmiyK ZIANqQFT84V7b41vTzHPvLmfO+Tw+9ICgcV5Hh04hLWlzGoeLuaK3JQ7HmwB/ema8zCz CXNUncfa5GN6h0IBBNgGo+4XIhkopjJ9hr0ZFkTQJ0bM6bApWIchrWfaByWfJyQO8HaI 1k+2daRGAFEpyULPxPp14p/UZoYBH3QZviD29Leu9ygpZfUL/cJqRAhGJtbceIIrPfye A5dEF3grp5rMCAFGMNpKMsvZqg+qf+w5bz+EcXjnmGK2SXo7LbGqgy8n7vJs+fIDA45C cbaw== X-Gm-Message-State: AMke39lBG33uNJ0WL1Xd8zyK/LtIawDquiD9FCHecWXR7rsLNBZW2F92JfkQ1WAQ1A+0knOt X-Received: by 10.223.179.78 with SMTP id k14mr21818967wrd.34.1487670848833; Tue, 21 Feb 2017 01:54:08 -0800 (PST) Received: from glumotte.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id 94sm28129474wrl.50.2017.02.21.01.54.08 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 21 Feb 2017 01:54:08 -0800 (PST) From: Olivier MATZ X-Google-Original-From: Olivier MATZ Date: Tue, 21 Feb 2017 10:54:00 +0100 To: Jan Blunck Cc: Olivier Matz , "Ananyev, Konstantin" , "dev@dpdk.org" Message-ID: <20170221105400.2eba4747@glumotte.dev.6wind.com> In-Reply-To: References: <1485271173-13408-1-git-send-email-olivier.matz@6wind.com> <2601191342CEEE43887BDE71AB9772583F111A29@irsmsx105.ger.corp.intel.com> <20170216144807.7add2c71@platinum> <20170217115153.0afeb061@platinum> <20170217151708.20bf4a49@platinum> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC 0/8] mbuf: structure reorganization 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: Tue, 21 Feb 2017 09:54:09 -0000 Hi Jan, On Mon, 20 Feb 2017 10:27:40 +0100, Jan Blunck wrote: > On Fri, Feb 17, 2017 at 3:17 PM, Olivier Matz > wrote: > > > > Sorry, I don't really get your point. My comprehension of the > > timestamp usage in a PMD is as following: > > > > rx_burst(struct rxq *rxq, ...) > > { > > unsigned long factor = rxq->timestamp_factor; > > unsigned port = rxq->port; > > > > for each hw_desc { > > m = rte_pktmbuf_alloc(rxq->pool); > > m->len = hw_desc->len; > > m->port = port; > > m->ol_flags = > > ... > > m->timestamp = hw_desc->timestamp * factor; > > } > > ... > > } > > > > In that case, I think it deserves to be in the 1st cache line. > > > > Timestamps are non-functional data. I believe they don't deserve to be > data normalized. I don't really see why timestamp is non-functional, compared to rss hash, flow director id, packet type, seqn, ... I think the goal of DPDK is to provide a generic/normalized API for such features (like for offload), so it can be used by an application whatever the underlying driver. > > It would be beneficial to normalize the access of non-functional data. > That would require some kind of extension or feature flags, e.g. like > some uverb structures support extensions. This would allow the NICs > that support timestamps to do the minimal amount of work during burst > and defer data normalization to the time of access. That would also > safe everyone from wasting 64bit in the first cacheline in case > timestamps are not supported or unused. I agree that we could start to think about "extensible" mbufs. In few words, I think we could have: - only general fields are static - the application registers room in mbuf structure for all features it will use It would rationalize the room used in mbuf, at the cost of a more complex/slow access to the data in PMDs and application, since the offset won't be static. But to me, this is another work, and a much harder one since it will impact a lot of PMD code (some are using vector instructions and are quite hard to change). Moreover, we first have to prove that it would perform better than we we have now, especially knowing that size of the cache line will probably change to 128B for many architectures. Now back on the patch, yes, it's true we are consuming 64bits in the first cache line. But what are the other options? Having it in the second cache line would allow free this space for future use. But don't you think we could optimize current use, and rework the structure if new needs -- that are more important than timestamp for the majority-- appear? Thanks, Olivier